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(57) ABSTRACT 

A system and method for a packet Voice Response Unit 
(VRU) which directly utilize packet network protocols, such 
as those of the H.323 standard, to provide enhanced services 
via a packet network. The packet VRU generally operates 
within the packet network and is not required to provide data 
format translation or multiple device-type access. The 
packet VRU may be built entirely in software running on a 
network server with a standard packet network connection 
such as Ethernet or token-ring. In a preferred embodiment of 
the present invention, the packet VRU redirects the media 
stream from a source so that it is sent directly to a 
destination, instead of passing through the packet VRU. 
Alternatively, if the packet VRU must perform processing 
on the message contents, the packets may be sent to both the 
destination and to the packet VRU. The packet VRU may 
still retain call control over the media streams by maintain- 
ing the signaling and user input components of the call. In 
another preferred embodiment of the present invention, a 
gateway may convert user input indication signals received 
from a party connected via the gateway into user input 
indication messages in an out-of-band channel to be read by 
the packet VRU, separate from the redirected media streams. 
The packet VRU may generally provide the existing 
enhanced services of a synchronous VRU but in a packet 
network environment, and in addition provide enhanced 
services for multimedia communications. 
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SYSTEM AND METHOD FOR PACKET 
NETWORK MEDIA REDIRECTION 

RELATED APPLICATIONS 

This application is related to the following commonly 
assigned, co -pending patent applications: Ser. No. 08/719, 
163, entitled INTERACTIVE INFORMATION TRANS- 
ACTION PROCESSING SYSTEM WITH UNIVERSAL 
TELEPHONY GATEWAY CAPABILITIES, by Michael 
Polcyn, filed Sep. 24, 1996; Ser. No. 08/846,961, entitled 
SWITCHLESS CALL PROCESSING, by Ellis Cave, filed 
Apr. 29, 1997; and Ser. No. 09/163,234, entitled INTER- 
ACTIVE INFORMATION TRANSACTION PROCESS- 
ING SYSTEM ON IP TELEPHONY PLATFORM, by J5 
Michael Polcyn, filed Sep. 29, 1998, which is a continuation 
of application Ser. No. 08/719,163; all of which applications 
are incorporated herein by reference. 

TECHNICAL FIELD 

20 

This invention relates generally to a system and method 
for facilitating the transfer of information via an asynchro- 
nous packet network, and more particularly to a system and 
method for redirecting media in an asynchronous packet 
network. 25 

BACKGROUND 

Voice Response Units ("VRUs") have existed in the prior 
art for many years, and are generally defined as robotic 3Q 
systems that automatically interact with one o r more 
persons for the exchange of information and the enhance- 
ment of communications. There are numerous enhanced 
services capable of being provided by a VRU, including 
voice messaging, automated collect calling, international 35 
callback, prepaid & postpaid calling card, store & forward, 
one number service, find me, follow me, 800/900 service, 
automated customer service, automated agents or attendants, 
voice activated dialing, prepaid & postpaid wireless, 
conferencing, and other such enhanced services. 4Q 

In the prior art, synchronously switched VRUs were 
initially connected to the Plain Old Telephone system 
("POTS") network (i.e., the Public Switched Telephone 
Network ("PSTN")) via analog interfaces. Although POTS 
analog connections still exist, the use of digitized voice 45 
transmissions is becoming increasingly common on the 
PSTN, Because of the advantages of digitized transmission, 
a synchronous VRU is now typically connected to the POTS 
network via a digital interface, as disclosed in co-assigned 
U.S. Pat No. 5,818,912, entitled FULLY DIGITAL CALL 50 
PROCESSING PLATFORM, by Daniel Hammond, issued 
Oct. 6, 1998, which application is incorporated herein by 
reference. An example of such a VRU is shown in FIG. 1, 
wherein synchronous VRU 100 is digitally connected to 
PSTN 102 via Tl trunk 104 using a standard Integrated 55 
Services Digital Network ("ISDN") format. Digitized voice 
signals transmitted over the PSTN normally consume 
approximately 64 Kilobits-per-second ("Kbps") of band- 
width when digitized and encoded according to the G.711 
compressed format using pulse code modulation ("PCM") 60 
and the standard /i-law or A-law logarithmic algorithms. 

Generally, in the prior art, the PSTN was originally 
designed to be managed and controlled by a single entity, 
and later developed such that very few entities control the 
primary switches that make up the network infrastructure. 65 
Generally, because control of the network is centered inside 
the PSTN switches and because the PSTN switches are of a 
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proprietary nature, very little control over the switching 
mechanisms is available to other entities that do not own the 
switches in the network. For example, each specific con- 
nection made by VRU 100, e.g., to telephone 106a, gener- 
ally requires its own port and a 64 Kbps channel. If the 
enhanced service being provided by VRU 100 requires 
connecting telephone 106a to another device external to 
VRU 100, for example to telephone 106c, there are limited 
options available to VRU 100, each with its own tradeoffs as 
explained below. 

First, PSTN 102 may transfer a call via Release Link 
Trunking ("RLT") by sending control signals to a switch in 
the network. For example, a calling party using telephone 
106a may wish to call another party at telephone 106c using 
an 800 calling card service provided by VRU 100. After the 
calling party enters a Card Number, personal identification 
number ("PIN") and the phone number for telephone 106c, 
VRU 100 verifies the information and then connects the two 
parties using RLT via PSTN 102, In using RLT, VRU 100 
gives up control of the call to PSTN 102, although VRU 100 
may send the customer's card number and PIN to PSTN 102 
for tracking purposes. Generally, a useful and desirable 800 
calling card service feature known as call re-origination 
allows the calling party to disconnect from the called party 
and reconnect to another called party without breaking the 
calling party's initial connection. Typically, the calling party 
on telephone 106a may hold down the # key for more than 
two seconds to signal to the network the calling party's 
desire to make a new call, although many other signals and 
durations may be used. Because VRU 100 has relinquished 
control of the call to PSTN 102, PSTN 102 must monitor the 
call for the # key dual-tone multi-frequency ("DTMF") 
signal so that PSTN 102 may then reconnect the calling 
party on telephone 106a to VRU 100. PSTN 102 also sends 
the customer ID and PIN back to VRU 100 so that the 
customer does not have to reenter this information. This 
approach has the advantage of freeing up the VRU ports for 
other callers, but it requires PSTN 102 to have an application 
running for tracking the customer's ID and PIN, and for 
monitoring the call for DTMF signals. 

Second, a user such as VRU 100 may use a hook flash to 
request that PSTN 102 directly connect telephone 106a to 
telephone 106c. This also has the advantage of freeing up 
ports on VRU 100, but VRU 100 permanently loses the call 
context. Unlike RLT, the hook flash does not allow VRU 100 
to retrieve the call context from PSTN 102. The VRU then 
cannot perform important call control or administrative 
functions such as monitoring, recording, timing, or charging 
for the phone call. Because the call context is lost for VRU 
100, the calling party generally must reenter the Card 
Number and PIN, in addition to the new destination phone 
number, and VRU 100 must re-verify the calling party's 
information. Reentering these numbers can be frustrating to 
customers, and consumes extra connection time and pro- 
cessing resources. 

Alternatively, the connection between the two parties may 
be bridged between the telephones within VRU 100. Internal 
synchronous switch 112 and another port and 64 Kbps 
channel are required to complete the connection to telephone 
106c. VRU 100 does not relinquish control of the call to 
PSTN 102, so VRU 100 may still perform call control and 
administrative functions. In addition, VRU 100 may monitor 
the call for DTMF signals. If in the calling party using an 
800 calling card service wishes to make another call, the 
calling party may hold the # key for more than two seconds. 
VRU 100 detects this signal directly, and can disconnect the 
called party on one port from the calling party on the other 
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port. Because VRU 100 maintained the call context, the munications Union ("ITU"), located in Geneva, Switzerland 
calling party's Card Number and PIN do not have to be and with a World Wide Web ("WWW") site of "http:// 
reentered and re-verified. The calling party may simply enter www.itu.org," has developed the H.323 standard for real- 
the new destination phone number, and VRU 100 may then time multimedia (defined herein as including voice, video, 
set up a new connection using another port. However, this 5 data, or any combination thereof) communications and 
alternative requires VRU 100 to implement internal switch conferencing for packet-based networks. The H.323 
112, and uses two circuits in the network and two ports on standard, entitled "Packet-based Multimedia Communica- 
VRU 100, one for each party. Thus the VRU ports generally tions Systems," released February 1998, is incorporated 
stay engaged for the entire duration of the phone call, instead herein by reference, and is actually an umbrella standard for 
of being made available for use on other phone calls. This is lQ a se ries of specifications that describe how multimedia 
undesirable because unlike a simple switch, VRU ports are communications occur between terminals, network equip- 
generally expensive resources that provide enhanced men t and services on packet networks (e.g., Internet Proto- 
functions, such as voice recognition, DTMF detection/ co l ("IF') networks), some of which do not provide a 
generation or text-to-speech conversion, for interacting with guaranteed Quality of Service ("QoS"). The standard is 
callers. Normally, the network owners would like to always J5 based on the Internet Engineering Task Force ("IETF") 
keep the VRU port busy handling new calls. However, since real-time protocol ("RTP") and real-time control protocol 
the VRU ports ate used to access the internal switch, the ("RTCF'), with additional protocols for call signaling and 
VRU ports are engaged during the entire call, even though data and audiovisual communications. Another protocol, the 
the port is idle. resource reservation protocol ("RSVP"), may be imple- 
In addition to internal switch 112 and extra network 20 mented in routers to establish and maintain requested trans- 
bandwidth used, a VRU bridged connection may also travel mission paths and QoS levels. Generally, a protocol that 
over an inordinate amount of distance. For example, a guarantees a QoS level has mechanisms for ensuring the 
calling party in Houston, Tex., may wish to call another on-time delivery of traffic signals, recovering lost packets, 
party in New Orleans, La., using an 800 calling card service and guaranteeing bandwidth availability for specific appli- 
provided by a VRU. If the VRU is located in either of those 25 cations. 

cities, then the bridged call does not travel much extra Some of the specifications referenced by the H.323 stan- 
distance compared to the physical distance between the dard include call control and framing specifications, such as 
actual parties. If the VRU is located in Los Angeles, Calif., H.225, Q.931, and H.245, audio codec specifications, such 
however, the inbound call to the VRU must travel all the way as G 711 f or high ^ rate connections and G.723 for 
to Los Angeles from Houston, and the outbound call from 30 low-bit-rate connections, video codec specifications, such as 
the VRU must travel all the way to New Orleans from Los H .261 for high bit rate connections and H.263 for low-bit- 
Angeles, which is an inefficient use of network resources. rate connections, and data communications specifications, 

Other problems with synchronously switched networks such as T.120 standards. The H.323 standard defines several 
exist. They generally are expensive to build, difficult to entities that may exist on a packet network: terminals, 
upgrade once built, and not flexible enough to support new 35 Multipoint Control Units ("MCUs"), gatekeepers, and gate- 
multimedia services. In response to these difficulties, along ways. Terminals support at least voice communications and 
with other factors, there has been a dramatic increase in optionally support multimedia communications, and include 
recent years of the availability of public packet networks, such components as personal computers and IP phones with 
such as the Internet, other wide area networks ("WANs"), at least voice capability and optionally multimedia capabil- 
and local area networks ("LANs"), to exchange information, 40 ity. MCUs support conferencing for three or more network 
for example, in voice format. PSTN circuits generally mul- endpoints. Gatekeepers provide network management and 
tiplex digitized voice signals by allocating sequential bits or virtual Private Branch Exchange ("PBX")-type capabilities, 
words in separate conversations to periodic time slots in a such as call control services like address translation for 
time division multiple access ("TDMA") structure. The network endpoints. Gateways support at least voice and 
PSTN requires a switched architecture and point-to-point 45 optionally multimedia inter-networking for connecting IP 
connections, and the data is transmitted continuously, so packet-based networks with circuit-switched networks, and 
PSTN connections use up bandwidth needlessly when provide translations between different transmission formats, 
voices are silent during a call. On the other hand, packet communications procedures, and codecs, 
networks asynchronously send digitized signals in pack- A synchronous VRU may interface with an asynchronous 
etized form, where each packet is encoded with a header that 50 packet network via a PSTN/packet gateway. APSTN/packet 
references its destinaUon and sequence. The packets are only gateway converts TDMA voice signals received, for 
sent when there is information to send, thus packet networks example, over a standard PSTN line, into packetized voice 
do not need to send packets when the callers' voices are signals, and vice versa, and allows the resources in the PSTN 
silent, saving bandwidth. network to exchange information with resources in the 

In a packet network, the packets may follow one of many 55 packet network. Generally, the PSTN/packet gateway also 
possible pathways to their destinations before they are performs conversion of analog signals to digital signals (if 
reassembled, according to their headers, into a conversation. required), or accepts the jU-law encoded digital signals 
Generally, this has the disadvantage over the POTS/TDMA direcdy from the PSTN. The gateway may optionally corn- 
method in that the packet headers consume additional band- press the digitized signals from /Maw (about 64 Kbps) down 
width. The packet header disadvantage is generally believed 60 to as low as about 5 Kbps before packetizing (and vice 
to be outweighed by the efficiencies in network usage versa). The packetized voice signals may be multiplexed 
without switched architecture and point-to-point connec- with numerous other signals for transmission over a data 
tions because, for example, a synchronous network continu- line. A typical application of such a PSTN/packet gateway is 
ously uses the same bandwidth even if there is no substan- providing an alternative to making a long distance call, 
live signal to transmit. $5 Instead of making a long distance connection where the 

In part to promote interoperability in the fast developing network uses digital TDMA lines at approximately 64 Kbps 

packet network technology area, the International Telecom- of bandwidth per call, callers may make a local POTS call 



1/3/05, EAST Version: 2.0.1.4 



US 6,404,746 Bl 

5 6 

to a PSTN/packet gateway. The gateway may digitize, if over a switched network (e.g., lower cost long distance), this 
necessary, and optionally compress the incoming signal type of implementation is probably best applicable as an 
down to about 5 or 6 Kbps. The gateway then packetizes the interim solution. For example, there may be some draw- 
signal. These packetized signals may then be multiplexed backs associated with the implementation described above, 
and routed in bulk very cheaply over long distances on a data 5 First, packet networks, not switched networks, appear to be 
grade network. At the other end, another PSTN/packet me dominant type of network for future communications, 
gateway receives and reassembles the packetized signal, and md thus the synchronous interface in a VRU may become 
then decompresses the signal, if necessary, and converts it j ess utilized 

back into a TDMA-multiplexed signal. Resources at the _ ' . , , mTT 
distant gateway then make another local POTS call to Second, even though a synchronous VRU may be con- 
complete the connection between the calling party and the 10 nected 10 a P acket network via a gateway, the VRU still 
receiving party. generally requires an internal switch to connect one party to 
A synchronous VRU connected to a PSTN/packet gate- another for man y enhanced services, such as calling card and 
way may provide the enhanced services described above, one-number services. When the call media stream passes 
and take advantage of the additional capabilities of the through the VRU, the application generally uses two ports to 
packet network. Such a system is one of the systems 15 complete the connection, and the VRU ports stay engaged in 
discussed in co-assigned, co -pending patent application Ser. the call for the duration of the call. Typically, prior art VRUs 
No. 08/719,163, entided INTERACTIVE INFORMATION switch synchronous data in G.711 format, which is the same 
TRANSACTION PROCESSING SYSTEM WITH UNI- format as used by the switches in the PSTN. Because of this, 
VERSAL TELEPHONY GATEWAY CAPABILITIES, by if data arrives in asynchronous G.711 format, or G.723 
Michael Polcyn, filed Sep. 24, 1996. An example of such a 20 format, the data must be converted to synchronous G.711 
system is shown in FIG. 2. As discussed in application Ser. format so that the VRU can process it. 
No. 08/719,163, the VRU (i.e., Interactive Voice Response Thirdj the repe ated conversions from one data format to 
Unit ("IVR")) may be an automated voice resource known another data format, such as from G.711 to G.723, or from 
in the art, such as the "OneVoice" or "IN'Control" synchronous to asynchronous, may delay or degrade the 
platforms, available from InterVoice, Inc., 17811 Waterview 25 data> and ^ use up processor reS ources which could be 
Parkway, Dallas, Tex., 75252. Ports on the VRU receive used for otner fictions more directly related to the core 
individual communications, and resources in the VRU per- functionality of the VRU. 

form processing to make communications in one format A tU * u tU u , roTT u - 

/ ^ , , . , , i\i i Another difficulty with a synchronous VRU being con- 

(e.g., asynchronous data in the packet network) understand- . i * *. i • * ■ *u * \mu 

\ , ' . . • *t c * * i ™ nected to a packet network via a gateway is that this VRU 

able to communications m other rormats (e.g. synchronous JU • . * * « • 4U * * i_- i_ • 

- . ™™ is architecturally m the position of a gateway, which is a 

data in the POTS network). . , „ , . L a * - n 

J . network edge device. These edge devices are generally 

In the example system shown m FIG. 2 synchronous ted to handk da , a translatioDS ^ multiplc device . 

VRU 200 connect to PSTN 202 via Tltrunk204, as m FIG. ^ ( voice> data modem aQd fox) lccess ^ ^ 

1. In addition, VRU 200 connects to PSTN/packet gateway network However> me signal processor ( « DS p») 

214 via Tl trunk 212, and gateway 214 is connected power ^ for yoice ovef Inteme , ^ ^jp,,) 

asynchronously to packet .network 216. If telephone 218 is compressioDi v .90 data modems, or fax modems, for 

physically located m a different area than VRU 200, access example; ^ relatively high. In a VRU, this processing power 

to VRU 200 via the POTS network may require a long wouW be beUer uti , ized p^^g enhanced KPlka ^ ^ 

distance phone call. To reduce the cost of this connection, as voice recognition ^ DTMF detection, which are more 

telephone 218 may access PSTN 220, which in turn provides related t0 the core fonctioiulily of the VRU. 

a synchronous connection to gateway 224 via Tl trunk 222. Mtemll i ve i y , tne data translation would be better placed in 

Because data m PSTN 220 is in G.711 format, gateway 224 a device which ^ j^ded to be a network edge device, such 

may translate the data into G.723 compressed format for „ a gatewaV) Mowing the ^ t0 ^ kss 

transmission over asynchronous packet network 216 or pr0C6Ssing p0W) wd mus bc more mst effici ent. 

gateway 224 may leave the data in G.711 format and not 4i _ t . , , 

change the compression format for transmission over packet ™* rc are ^ enhanced se ™ ce * P rovid * d °^ . the 

network 216. Gateway 224 also provides the appropriate PS ™ n K ctw ° rk * at « "PPl»b1e to and useful in a 

headers for routing the packets to gateway 214. Gateway Packet-based network. Generally, customers will still want 

214 may then decompress the reassembled packets, if * e ^ of enhanced services provided by VRUs even if 

necessary, from G.723 format and translate the data into 50 they are using a packet network instead of the POTS 

G.711 format for transmission to VRU 200 over Tl trunk network, and even if the media contains voice, video, data, 

212. As with the system in FIG. 1, each specific connection or a ™™ b ™t™ thereo£ > ****** of volce ^ 

made by VRU 200 generally requires a port and a 64 Kbps Tte* and olher objects, features and technical advan- 

channel on Tl trunk 212. If the enhanced service being kg** m generally achieved by a system and method for a 

provided by VRU 200 requires connecting telephone 218 to 55 packet VRU which directly utilizes packet network 

another device external to VRU 200, for example to tele- protocols, such as those of the H.323 standard, to provide 

phone 206 or telephone 232, then internal synchronous enhanced services in a packet network. The VRU may 

switch 238 and another port and 64 Kbps channel are directly connect to the packet network as a network "core" 

required to complete the connection. In addition, if the device, or connect via another network core device, such as 

connection to the external device is back through gateway 60 *n H.323 gatekeeper. In contrast to a network edge device 

214 and packet network 216, the entire sequence of ( e g> a gateway), a network core device (e.g., a gatekeeper 

compression/decompression, if necessary, and translation or a router) generally operates "within" the packet network 

must be performed again. an d ^ not required to provide data format translation (e.g., 

ciTuuADvncTunTMvrwrrnM synchronous to asynchronous) or multiple device-type 

SUMMARY OF THE INVENTION 65 acccss (c g , fax ^ modcm) . Advantageously, the packet 

While a synchronous VRU connected to a gateway may VRU may be built entirely in software running on a network 

take advantage of many of the benefits of a packet network server with a standard packet network connection such as 
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Ethernet or token-ring. The H.323 software protocol may Accordingly, it is highly desirable for the packet VRU to 
contain all of the call placement, progress, and termination reduce or avoid these delays, while at the same time main- 
functions, implemented as out-of-band signaling in a format taining control of the call. In a preferred embodiment of the 
similar to ISDN's Q.931 standard. invention the packet VRU may utilize protocols available in 
In a preferred embodiment of the present invention, a 5 the packet network to redirect a source's media stream from 
packet VRU may connect two or more parties together via the packet VRU to another destination. In this way the media 
the packet network, such as for an 800 calling card service stream is sent directly to the destination instead of passing 
or for a teleconferencing service. Analogous to the discus- through the packet VRU. Alternatively, if the packet VRU 
sion above with respect to the synchronous VRU connected must perform processing on the message contents, the 
to the PSTN, it is desirable for the packet VRU to be able to 1Q packets may be directed to the receiving parties, and in 
connect two or more parties together and still maintain addition continue to be sent to the packet VRU. By redi- 
control of the call. This includes call administrative recting the packets directly to the receiving parties, these 
functions, tracking call context, processing input from users, embodiments generally avoid any additional compression, 
etc. Therefore it is generally useful for a packet VRU to packetization and jitter delays that would be introduced by 
maintain control of the call and receive user input, signaling, a second subsequent media stream from the VRU to the 
or the audio stream, for example to detect user input 13 destination 

indication (e.g., DTMF) messages, interpret voice input or f embodiment, the packet VRU generally 

sum voices in a conference call. One way to accomplish this / , , u ^ f* <- ^ 6 wiwaujr 

is for the packet VRU to receive and process the packets sent redirects only the media streams themselves to be sen 

by a source, and then re-transmit the packet information to between the parties The packet VRU may still 

the proper destinations 20 retain call control over the media streams by maintaining the 

However, there are generally three important sources of si S nali °g ^^JT % J com P onents °f *e catt. *> r 

delay encountered when transmitting data across a packet example, the RTP/RTCP media streams may be redirected to 

network. First, there is a delay introduced if the data is be sort directly between the gateways, but the H.245 and 

compressed by the source. Generally, the source gateway Q-931 call structures between the gateways and the VRU 

must receive and store enough data in order for it to execute 25 mav DC ^ e P l intact. 

the compression algorithm. Depending on the specific algo- In H.323 VoIP architecture, the DTMF or other user 

rithm used, compression can introduce, for example, 30 signaling may be taken out-of-band from the RTP streams 

msec of delay into the signal. Second, there may be a delay using H.245 Userlnputlndication messages, as described in 

introduced by the source converting the data from non- more detail in section 7.12.6 of the H.245 specification. This 

packet form into packet form. Generally, the source gateway 30 feature was specified in the H.323v2 specification because 

must receive and store a certain amount of data to fill a some voice compression schemes destroy in-band DTMF 

packet, and then generate a header to affix to the packet data. information. This feature was inteDded to allow out-of-band 

This packetization can introduce, for example, 50 msec of DTMF information to be sent to the same endpoint as the 

delay into the media transfer. Third, there may be a delay due in-band voice information, but this feature may also be 

to the inherent asynchronous nature of a packet network. 35 exploited to route the user input to a different endpoint than 

Generally, packets arrive at a destination at varying times, the RTP media stream. H.245 section 7.12.6 User Input also 

and may even include overlapping and out-of-sequence describes a method to provide DTMF duration information 

packets. For the transferring of data files, this "jitter" gen- in the Userlnputlndication messages using Signal and Sig- 

erally does not introduce any significant problems because nalUpdate parameters. This feature may be used to transfer 

the data is not time critical. For real-time data, however, 40 tone duration information out-of-band from the RTP 

such as voice, video or multimedia data, a jitter buffer may streams. Tone duration is useful in many applications, such 

be necessary to reconstruct the packets into a real-time as calling card call re-origination. 

message. The jitter buffer can introduce, for example, 100 Thus in a further preferred embodiment of the present 

msec of delay into the media stream because it must com- invention, a gateway or browser may convert user input 

pensate for the jitter in the arrival of the packets. 45 indication signals (e.g., DTMF signals from a telephone, or 

These compression, packetization and jitter delays may keyboard input from an IP phone) received from a party 

all be present in any transfer of data from a source to a connected via the gateway or browser into user input indi- 

destination in a packet network. If a packet VRU receives cation messages in an out-of-band channel in the H.323 

packetized data from a source and then re -transmits the protocol to be read by the packet VRU, separate from the 

packetized data to a destination, all three delays may be 50 redirected media streams. This may be especially useful for 

present in each separate media stream (i.e, from the source higher compression schemes (e.g., G.723) which cannot 

to the VRU, and from the VRU to the destination). Adding properly compress and decompress user input indication 

the second set of delays to the transfer may be unacceptable signals in-band with the voice signal. By using user input 

for real-time media communication. In addition, there may indication messages, the packet VRU advantageously does 

be excess delay associated with the transportation of the two 55 not need to receive the media streams if the sole reason is to 

(or more) separate media streams in the network, especially detect user input indication signals, and this approach also 

if the originating and terminating parties are located close to circumvents the digital signal processing associated with 

each other and the packet VRU is located far from the in-band user input indication detection. Thus the packet 

parties. Generally, this delay may be caused both by the VRU may redirect the media streams to travel directly 

increased distance that the signals must travel, and by all the 60 between the parties without passing through the packet 

extra routers and switches and other circuitry which the VRU, and still maintain call control, including receiving 

signals must pass through in the network. Users are very user input indication messages from the users. Alternatively, 

sensitive to delay, which can be distracting at the least, and if the receiving party also needs to receive user input 

may cause parties to start talking over one another if the indication signals, for example if the receiving party is a 

delay becomes too excessive, significantly disrupting the 65 synchronous VRU monitoring user input indication signals, 

conversation. Delay may even cause sufficient user dissat- then either the originating gateway or the packet VRU can 

isfaction to push users to seek another service provider. send the user input indication messages to the destination 



1/3/05, EAST version: 2.0.1.4 



US 6,404,746 Bl 



10 



gateway, which may then convert the messages back into 
actual user input indication signals added into the voice 
signal. 

In an alternative embodiment, the packet VRU may solely 
utilize a voice-recognition user interface and therefore not 
require user input indication signals at all. Alternatively, if 
the user input indication signals are implemented in-band 
with the data channel, a user input indication detector in the 
packet VRU may be implemented, and for further function- 
ality a user input indication generator may also be imple- 
mented in the packet VRU. For these latter two 
embodiments, in addition to the media streams being trans- 
ferred directly between the parties, the packet VRU would 
also need to receive copies of the media streams to process 
the data contained in them. One example of a standard for 
user input indication data transfer and reproduction is the 
"Voice over IP Interoperability Implementation Agreement," 
developed by the International Multimedia Teleconferenc- 
ing Consortium ("IMTC"), located in San Ramon, Calif, and 
with a WWW site of "http://www.imtc.org/* The 
specification, which supports two party voice and voice- 
band calls over IP networks, is based on H.323 standards and 
includes other telephony-specific requirements and IP spe- 
cific needs such as directory services and dynamic IP 
address resolution mechanisms. 

In accordance with a preferred embodiment of the present 
invention, a method for redirecting media in an asynchro- 
nous packet network by a system asynchronously connected 
to the packet network comprises establishing a first call 
between a first device and the system via the packet network, 
wherein the first call comprises a first call control structure 
and a first media stream, and signaling the first device to 
redirect the first media stream to a second device, wherein 
the first call control structure is retained between the first 
device and the system. In a further aspect of this preferred 
embodiment, the method farther comprises establishing a 
second call between the system and the second device via 
the packet network, wherein the second call comprises a 
second call control structure and a second media stream, and 
signaling the second device to redirect the second media 
stream to the first device, wherein the second call control 
structure is retained between the system and the second 
device. 

In accordance with another preferred embodiment of the 
present invention, a computer program product having a 
computer readable medium with computer program logic 
recorded thereon for use in a system asynchronously con- 
nected to a packet network for redirecting media in the 
asynchronous packet network, comprises code for establish- 
ing a first call with a first device via the packet network, 
wherein the first call comprises a first call control structure 
and a first media stream, code for establishing a second call 
with a second device via the packet network, wherein the 
second call comprises a second call control structure and a 
second media stream, code for signaling the first device to 
redirect the first media stream to the second device, and code 
for signaling the second device to redirect the second media 
stream to the first device, wherein the first and second call 
control structures are not redirected away from the system. 

In accordance with yet another preferred embodiment of 
the present invention, a system for redirecting media in an 
asynchronous packet network comprises an asynchronous 
interface to the packet network, means for establishing a first 
call with a first device via the packet network, wherein the 
first call comprises a first call control structure and a first 
media stream, means for establishing a second call with a 
second device via the packet network, wherein the second 
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call comprises a second call control structure and a second 
media stream, means for signaling the first device to redirect 
the first media stream to the second device, and means for 
signaling the second device to redirect the second media 
stream to the first device, wherein the first and second call 
control structures are not redirected away from the system. 

In accordance with still another preferred embodiment of 
the present invention, a system for redirecting media in an 
asynchronous packet network comprises an asynchronous 
interface to the packet network, a call control server, 
wherein the call control server sets up call control structures 
to communicate with devices in the packet network via the 
asynchronous interface for controlling media streams from 
and to the devices, a voice media server communicating with 
the call control server, wherein the call control server uses 
the call control structures to establish media streams 
between the devices and the voice media server via the 
asynchronous interface, and an application server commu- 
nicating with the call control server and the voice media 
server, wherein the application server instructs the call 
control server to redirect the media streams to be transmitted 
directly between the devices without passing through the 
system, and wherein the call control structures are retained 
between the devices and the system. 

One advantage of a preferred embodiment of the present 
invention is that a packet VRU may generally provide the 
existing enhanced services of a synchronous VRU, but in a 
packet network environment. Another advantage of a pre- 
ferred embodiment of the present invention is that a packet 
VRU may provide enhanced services for multimedia com- 
munications in addition to voice-only communications. 
Because of the added multimedia functionality, a packet 
VRU may also be described as a packet Multimedia 
Response Unit ("MRU"), or a packet Interactive Multimedia 
Response ("IMR") Unit. All such systems may also be 
referred to as a packet Enhanced Service Provider ("ESP"). 
Of course, with the added multimedia functionality, new 
enhanced services, such as video conferencing, shared 
whiteboarding and text chatting, which were not imple- 
mented in voice-only communications, will become 
desirable, and all such enhanced services are intended to be 
within the scope of the present invention. 

A further advantage of a preferred embodiment of the 
present invention is that repeated conversions from one data 
format to another data format are avoided because the media 
is sent directly from source to destination, and not through 
the packet VRU. In addition, because the packet VRU is 
implemented as a core device within the packet network 
instead of as an edge device, the packet VRU does not need 
to provide multiple device-type access such as for modems 
and fax machines. Instead, gateways generally direct only 
the voice calls to the packet VRU and direct fax and modem 
calls elsewhere. Also, the packet VRU may not need to 
provide data format conversion between the packet network 
and another type of network, such as a switched network, 
although connecting a combined packet/synchronous VRU 
to both types of networks may still be desirable for some 
applications. 

A further advantage of a preferred emtx)diment of the 
present invention is that a packet network interface generally 
does not require multiple physical ports and an internal 
switch for connecting more than one party together for 
enhanced services such as calling card and one-number 
services. Instead, any switching/routing is handled in the 
packet network itself. A single packet network interface may 
handle all traffic with the packet VRU. For example, a single 
100 Mbit Ethernet interface may carry over 10,000 5 Kbit 
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G.723 compressed voice channels plus overhead. 
Alternatively, more than one packet network interface may 
be implemented. In addition, multiple parties may be con- 
nected by redirecting the media streams to travel directly 
between the parties, without passing through the VRU. Thus 
the packet VRU may avoid the delays associated with an 
internal jitter buffer, internal processing of the packets, and 
separate media streams from the VRU to each party. 

A further advantage of a preferred embodiment of the 
present invention is that a packet VRU may redirect the 
media streams and still retain control of the call by keeping 
the call states between the parties and the VRU intact. 
Redirecting the media streams may free up valuable 
resources in the packet VRU, such as voice recognition 
resources, so that they can be used to handle other calls. In 
addition, the packet VRU may still receive user input 
indication messages. This embodiment has a further advan- 
tage over a synchronous VRU in that it can perform a 
function similar to RLT in the PSTN, discussed above, but 
still monitor for user input indication signals and still keep 
track of the call context. Thus the packet VRU, and not the 
network, would monitor for user input indication signals. 
For example, if the packet VRU redirects a calling card 
caller's call from a third party to the VRU in response to a 
user input indication message, the calling card caller would 
not have to re-enter Card Number and PIN information to 
make a second calling card call. 

Yet another advantage of a preferred embodiment of the 
present invention is that generally only the amount of 
bandwidth needed is used in the packet network interface 
(and throughout the packet network), instead of the 64 Kbps 
channels generally required for each connection in a 
switched network. 

The foregoing has outlined rather broadly the features and 
technical advantages of the present invention in order that 
the detailed description of the invention that follows may be 
better understood. Additional features and advantages of the 
invention will be described hereinafter which form the 
subject of the claims of the invention. It should be appre- 
ciated by those skilled in the art that the conception and 
specific embodiment disclosed may be readily utilized as a 
basis for modifying or designing other structures for carry- 
ing out the same purposes of the present invention. It should 
also be realized by those skilled in the art that such equiva- 
lent constructions do not depart from the spirit and scope of 
the invention as set forth in the appended claims. 

BRIEF DESCRIPTION OF THE DRAWING 

For a more complete understanding of the present 
invention, and the advantages thereof, reference is now 
made to the following descriptions taken in conjunction with 
the accompanying drawing, in which: 

FIG. 1 is a block diagram of a prior art synchronous VRU 
connected to a PSTN; 

FIG. 2 is a block diagram of a synchronous VRU indi- 
rectly connected to a packet network via a gateway; 

FIG. 3 is a block diagram of a packet VRU implemented 
on a packet network in which two users are connected to 
each other from gateway to gateway in a connection con- 
trolled by the VRU; 

FIGS. 4a-4d are a series of block diagrams illustrating a 
sequence for redirecting media within a packet network; 

FIG. 5 is a flow diagram illustrating a message protocol 
for redirecting media using communication mode command 
procedures; 
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FIG. 6 is a flow diagram illustrating a message protocol 
for tearing down redirected media using communication 
mode command procedures; 

FIG. 7 is a flow diagram illustrating a message protocol 
5 for redirecting media using user input indication messages; 
and 

FIG. 8 is a flow diagram illustrating a message protocol 
for tearing down redirected media using user input indica- 
tion messages. 

10 

DETAILED DESCRIPTION 

FIG. 3, is a block diagram of a preferred embodiment of 
the present invention in which packet VRU 600 is connected 
to packet network 602 via asynchronous Ethernet interface 

15 604. Packet VRU 600 is capable of using H.323 protocols or 
other packet network protocols to communicate with other 
devices in packet network 602. In this embodiment, packet 
VRU 600 communicates directly with gateway 606, via the 
packet network side, to allow connection of multiple devices 

20 that are external to packet VRU 600. By communicating 
with gateway 606, packet VRU 600 can effectively perform 
those enhanced services which require switching (e.g., 800 
calling card service and one number service) in the synchro- 
nous VRUs illustrated in FIGS. 1 and 2, but without requir- 

25 ing an internal hardware switching mechanism. 

Packet VRU 600 includes data processor 620 and memory 
622. Data processor 620 may be a processor board contain- 
ing one or more general purpose processors, DSPs, or 

3Q custom processors. Memory 622 may be any type of typical 
storage device used in computers such as a magnetic or 
optical disks, non-volatile or volatile RAM or magnetic tape. 
Data processor 620 provides control and interactive com- 
munication with users and handles user requests, while 

35 memory 622 provides storage for outgoing messages or 
message components and for recording user input. 

Similar to the network discussed above with respect to 
FIG. 2, gateway 606 is connected to packet network 602 via 
a packet-based interface. Gateway 606 provides a network 

40 bridge between packet network 602 and PSTN 608, and thus 
to the devices connected to PSTN 608, such as telephone 
618, data modem 610 and fax machine 612. Other devices 
which may connect to packet network 602 include multi- 
media personal computer ("PC) 614 and gatekeeper 616, 

45 both of which are capable of using H.323 protocols to 
communicate with other devices in packet network 602. 

In order for telephone 618 to connect to VRU 600, 
telephone 618 must first connect to originating gateway 606 
via PSTN 608, generally using a G.711 data format Gate- 

50 way 606 may optionally transcode the G.711 format into a 
higher compression/lower data rate format, such as G.723 
format. Gateway 606 then packetizes the data and attaches 
the appropriate headers to the packets for transmission to 
packet VRU 600 across packet network 602. Because packet 

55 VRU 600 is connected to packet network 602 as a network 
core device, packet VRU 600 generally does not need to 
provide multiple device -type (e.g., voice, fax and data 
modem) access to the packet network. These functions are 
performed by gateway 606 as a network edge device in 

60 linking PSTN 608 to packet network 602; gateway 606 
generally routes only voice calls to packet VRU 600. 

An H.323 call using Q.931 signaling and H.245 call 
control is set up between gateway 606 and packet VRU 600 
via packet network 602. Packet VRU may then set up an 

65 RTP/RTCP media stream between packet VRU 600 and 
gateway 606. Generally only media data is transmitted over 
the media stream, not call control or user input indication 
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signals. To connect telephone 618 to another party, such as 
telephone 630, packet VRU 600 sends control signals to 
gateway 606 to redirect the media stream to another device 
linked to packet network 602, such as destination gateway 
626. This preferred embodiment is somewhat similar to RLT 
in a switched network, but with the important difference that 
packet VRU 600 can still maintain control of the call 
because packet VRU 600 does not redirect the call control 
signals. Advantageously, the extra set of delays associated 
with the packets first being received and processed by packet 
VRU 600 and then transmitted to gateway 626 are generally 
eliminated. In addition, the processing requirements for 
packet VRU 600 are generally reduced because all routing 
and data handling can be performed by gateway 606. If 
packet VRU 600 does not need to process the content of the 
data stream, it can request that gateway 606 only send the 
packets across packet network 602 to telephone 630 via 
gateway 626. Alternatively, packet VRU 600 may request 
that gateway 606 replicate the data packets and send them to 
packet VRU 600 for processing, in addition to forwarding 
the data on to telephone 630. Call control and a return media 
stream from gateway 626 to gateway 606 may be set up in 
a manner similar to that described above for gateway 606. 

FIGS. 4a-4d illustrate a sequence for redirecting media 
on a packet network in accordance with another preferred 
embodiment of the present invention. FIGS. 4a-4d illustrate 
how to connect a caller to a called party using an 800 calling 
card enhanced service as an example application. Of course, 
the inventive concepts are applicable to any enhanced ser- 
vice in which a packet VRU connects a party to one or more 
other parties via a packet network. In general, the calling 
party may be a person, such as a customer, or may be a 
robotic resource, such as another packet VRU. The other 
party may be another person, such as another customer or an 
agent, or may be a robotic resource, such as an automated 
agent, or another VRU. Some of the details shown in FIG. 
3, such as fax machines and modems, are omitted from 
FIGS. 4a-4d for clarity, but the discussions with respect to 
FIG. 3 are still applicable to the embodiment illustrated in 
FIGS. 4a~Ad 

With reference to FIG. 4a, there is shown VRU 800 
asynchronously connected to IP network 806, for example 
via an Ethernet connection. VRU 800 includes call control 
server ("CCS") 802, voice media servers) ("VMS") 804, 
and application server 803. An NSP-5000, available from 
InterVoice, Inc., 17811 Waterview Parkway, Dallas, Tex., 
75252, with Calling Card and VoIP capability may be used 
to implement VRU 800. Domain gatekeeper 808 is also 
connected to IP network 806, and maintains a directory of IP 
addresses for the various devices in the network. Also 
present on the network are gateways with VoIP capability, 
such as originating gateway 810 and terminating gateway 
812 (also referred to herein as destination gateway). 

In this preferred embodiment the VRU provides an 800 
calling card service. In a standard 800 calling card service, 
a caller dials the 800 service access number for the VRU. 
The VRU carries on an interactive dialog with the caller in 
order to obtain the caller's Card Number, PIN and the PSTN 
phone number for a desired party with whom the caller 
wishes to communicate. The VRU verifies the PIN and 
attempts to connect the caller to the desired party. The 800 
calling card service may be a prepaid or postpaid service. In 
either case, the VRU generally needs to monitor the duration 
of the phone call in order to charge the caller the correct 
amount of money for the phone call. If a preset or prede- 
termined limit is in effect, (i.e., either the amount of money 
on a prepaid calling card, or a ceiling on the amount of credit 
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allowed for a postpaid card), then the VRU also needs to 
monitor and have control over the phone call so that the call 
can be terminated if the limit is reached or exceeded. 
In FIG. 4a, a caller using POTS telephone 814 dials the 

5 800 service access number. The PSTN network routes the 
call 816 to originating gateway 810. Preferably, originating 
gateway is physically located close to the caller, so that 
minimal cost is incurred in the PSTN network. The service 
provider for the 800 calling service may have gateways 

10 located throughout a country, for example in the major cities 
in the United States. In a preferred embodiment, the original 
800 call is routed to the closest gateway in the PSTN. 
Alternatively, the original 800 call is always routed to a 
specific gateway, irrespective of the location of the caller. 

15 Originating gateway 810 receives the call from the PSTN, 
and queries 818 domain gatekeeper 808 via IP network 806 
for the PSTN-number-to-IP address translation, which is 
sent back 818 to gateway 810 by gatekeeper 808. 

Originating gateway 810 then establishes H.323 call 820 

20 to CCS 802 in VRU 800. Q.931 call signaling identifies the 
source and destination and establishes a virtual signal con- 
nection between gateway 810 and VRU 800. The signaling 
connection is established when the H.323 Stack signals that 
the call is in the connected state. Then the H.245 call control 

25 process exchanges capabilities between gateway 810 and 
VRU 800, and is complete when gateway 810 and VRU 800 
have established inbound and outbound logical channels 
between each other. Once the inbound and outbound logical 
channels (User Datagram Protocol ("UDP") addresses) are 

30 known, an RTP/RTCP session can be established for trans- 
ferring media streams between gateway 810 and VRU 800. 

CCS 802 determines caller ID and called number infor- 
mation from the H.245-Q.931 data. CCS 802 uses the caller 

35 ID and called number information to determine the type of 
service (application) to be applied to the incoming call, in 
this case 800 calling card service, by application server 803, 
which initiates the appropriate application. CCS 802 also 
selects the port in VMS 804 to be used to handle the call, and 

4Q sends the card application context data 822 to VMS 804. 
CCS 802 directs originating gateway 810 to send its RTP 
stream to a media port on VMS 804. Similarly, VMS 804 is 
directed by CCS 802 to send its RTP stream to originating 
gateway 810, thus establishing a full duplex audio connec- 

45 tion 824 between originating gateway 810 and VMS 804. As 
discussed hereinabove, gateway 810 is an edge device, and 
provides for translation between synchronous PSTN and 
asynchronous IP network 806. 

Application server 803 may then command VMS 804 to 

50 execute an interactive voice script with the caller to provide 
voice greetings and menus. The script obtains the caller's 
Card Number, PIN and the PSTN phone number that the 
caller wishes to reach, in this case the phone number for 
POTS phone 832. POTS phone 832 is connected to IP 

55 network 806 via the PSTN and gateway 812. Application 
server 803 validates the Card Number and PIN in its 
customer card database. 

Turning now to FIG. 4b, application server 803 directs 
CCS 802 to place a separate, secondary call to POTS 

60 telephone 832, which has the PSTN number specified by the 
caller. To accomplish this, CCS 802 first queries 826 gate- 
keeper 808 to find the IP address of the appropriate gateway 
to reach the called PSTN number, in this case terminating 
gateway 812. Gatekeeper 808 returns 826 the IP address of 

65 gateway 812 to CCS 802. CCS 802 then places a second 
H.323 call 828 to terminating gateway 812 by using the IP 
address provided by gatekeeper 808. When terminating 
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gateway 812 responds to H.323 call 828, CCS 802 directs each party to every other party. The primary difference from 

terminating gateway 812 to send its RTP stream to an IP the method discussed above with respect to FIGS. 4a-4c is 

address on VMS 804. Similarly, VMS 804 is directed to send that the media stream from each party is redirected to be 

its RTP stream to terminating gateway 812, thus establishing transmitted to more than one destination. In one alternative 

a second fall duplex audio connection 830 (two opposite 5 embodiment, the participants or the equipment in their paths, 

direction RTP sessions) between terminating gateway 812 such as their respective gateways, have the ability to perform 

and VMS 804. the summation of the incoming signals themselves, and 

Finally, to reach the desired party, CCS 802 instructs VRU 800 is not required to receive the media streams. In 

terminating gateway 812 to extend H.323 call 828 into the another alternative embodiment, the participants do not 

PSTN using the POTS number provided by the caller. 1Q perform the summation of the incoming media streams, so 

Terminating gateway 812 complies by placing PSTN call VRU 800 receives each of the media streams, performs the 

834 to the called party on POTS phone 832. Application summation of the signals, and sends the media streams out 

server 803 monitors the call progress, and when answer to each of the participants. In either case, and as discussed 

occurs, application server 803 instructs VMS 804 to execute above, VRU 800 retains control of the call by leaving the 

an interactive voice script with the called party. The script 15 H.323 calls intact. Also as discussed above, VRU 800 may 

may provide voice greetings with screening and identifica- still monitor for user input indication messages transmitted 

tion of the called party. At this point there are two separate via the H.323 calls. 

connections established via IP network 806 , from POTS Turning to FIG. 4d, in another preferred embodiment, a 

phone 814 to VRU 800, and from VRU 800 to POTS phone caller may wish to place another phone call after completing 

832. 20 a prior phone call without repeating the entire procedure of 

Turning now to FIG. 4c, there is illustrated a preferred dialing the 800 number and entering in the Card Number and 

embodiment of the invention, in which media sent to VRU PIN. The only new information required from the caller to 

800 is redirected to travel directly between the originating perform the re-origination function is the new destination 

gateway 810 and terminating gateway 812, thus bypassing telephone number. To make a new call, caller holds down the 

VRU 800. Once the called party is validated, application 1S pound key on POTS telephone 814 for longer than 2 

server 803 instructs CCS 802 to redirect the media streams. seconds. Originating gateway 810 relays this signal to CCS 

CCS 802 requests that originating gateway 810 and termi- 802 via out-of-banduser input indication signaling on H.323 

nating gateway 812 send their respective RTP streams call 820. Upon receiving indication that the caller desires to 

directly to each other, instead of to VMS 804. CCS 802 make another telephone call, application server 803 instructs 

accomplishes this by tearing down RTP session 824 between 30 CCS 802 to tear down H.323 call 828 to terminating 

originating gateway 810 and VMS 804, and by tearing down gateway 812 and RTP streams 836 and 838. Originating 

RTP session 830 between terminating gateway 812 and gateway 810 may use the key-on key-off Userlnputlndica- 

VMS 804. Only RTP sessions 824 and 830 are torn down; tion messages for user input indication carriage in accor- 

H.323 call 820 between originating gateway 810 and VMS dance with H.245v3. Only originating H.323 call 820 is left 

804, and H.323 call 828 between terminating gateway 812 35 active. 

and VMS 804, are left connected. To make the new phone call, application server 803 

To establish communications directly between the instructs CCS 802 to re-establish a full-duplex RTP session 

gateways, CCS 802 requests that originating gateway 810 with a media port on VMS 804, as discussed with respect to 

redirects its RTP stream 836 to terminating gateway's 812 RTP stream 824 in FIG. 4a. Also similar to the discussion 

media port. Likewise, CCS 802 requests that terminating 40 ^th respect to FIG. 4a, application server instructs VMS 

gateway 812 redirect its RTP stream 838 to originating 804 to execute an interactive voice script with the caller. The 

gateway's 810 media port. Again, the H.323 call states are script provides voice greetings and menus. Since the service 

not modified, only the RTP streams are moved. Thus CCS application has already validated the caller, the script only 

802 may still monitor out-of-band user input indication needs to obtain the next PSTN phone number that the caller 

signaling on the originating leg of H.323 call 820 from the 45 wishes to reach. Once the new phone number is obtained, the 

calling party via originating gateway 810. VRU 800 may process is repeated again as discussed with respect to FIGS, 

still monitor and control the communication between the 4£>-4c. If the caller hangs up, all H.323 calls are torn down 

calling and called parties via H.323 calls 820 and 828, but and caller context is discarded. 

data sent between the calling and called parties travels via Generally, there are many ways to redirect a media stream 

RTP streams 836 and 838 and no longer needs to pass so in a packet network without affecting call control, and all 

through VRU 800. Alternatively, for some enhanced such systems and methods are intended to be within the 

services, VRU 800 may still need to monitor the contents of scope of the present invention. Media redirection may be 

the call between the calling and called parties. In that case, implemented using custom functionality in the packet 

VRU 800 may not tear down the original RTP streams and network, or it may be implemented in compliance with a 

instead simply establish the new RTP streams, which are 55 defined methodology, such as by using functionality 

copies of the original RTP streams. Once the call is described in the H323 specification, 

terminated, either by one of the parties or by the VRU, Some of these systems and methods have been tested in 

application server 803 instructs CCS 802 to tear down RTP the laboratory for viability. The laboratory setup comprised 

streams 836 and 838, and H.323 calls 820 and 830. VRU 800 a VRU system including an InterVoice ISA VCD card, a 

may also complete any administrative tasks, such as statis- 60 Natural MicroSystems ("NMS") Ag4000 card, an NMS 

tical recording or billing calculation and recording. Tx3210 card, NMS Fusion 3.0 software, and application 

Alternatively, a similar approach may be used to establish software implementing the media redirect functions 

connections between more than two parties external to VRU described herein. The laboratory setup also comprised two 

800, for example to provide a conferencing application. gateway systems, each including an NMS Ag8 card, an 

VRU 800 sets up multiple H.323 calls and associated RTP 65 NMS T1/RT2 card, an NMS Tx2000 card, NMS Fusion 2.0 

media streams to each party participating in the conference, software, and a sample application software implementing 

and then redirects the media streams to be transmitted from the gateway functions described herein. The NMS products 
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are available from Natural MicroSystems, 100 Crossing 
Boulevard, Framingham, Mass., 01702-5406. The Fusion 
H.323 Stack Programmer's Guide and Reference, NMS P/N 
6448-12, incorporated herein by reference, provides more 
detailed information about the NMS Fusion software. 

H.323 section 8.3.5, entitled "Communication Mode 
Command Procedures" describes functionality that may be 
used to implement the present invention: 

The CommunicationModeCommand can be used to 
instruct endpoints in a conference (or a point-to-point 
call) to change modes by indicating a new mode for a 
mediaChannel that is already in use. It can also be used 
to tell an endpoint to transmit the media stream to a new 
address by indicating the mode currently in use, but 
with new mediaChannel. Similarly, an endpoint that 
receives a CommunicationModeCommand indicating 
the mode currently in use and no mediaChannel should 
close the appropriate channel and the attempt to reopen 
using the OpenLogicalChannel- 
OpenLogicalChannelAck sequence, where the Open- 
LogicalChannelAck contains the address to which the 
endpoint will send the media. 
In accordance with a preferred embodiment of the present 
invention, FIG. 5 illustrates a message protocol 900 for 
redirecting media using the Communication Mode Com- 
mand Procedures. This approach generally uses the com- 
munication mode of multicasting and the decentralized 
conference characteristics described in the H.323 standard. 
In order to implement media redirection in this manner, the 
participating gateways generally should support the Confer- 
ence mode described in section 8.3.5 of the H.323 specifi- 
cation. The VRU generally should be identified as a Multi- 
point Controller f'MC) entity under the H.323 standard. In 
addition, to initiate the Conference mode, a VRU generally 
should be the master terminal endpoint on the call, so the 
gateway routing calls to the VRU generally should be 
configured to allow slave status. Preferably, the conferences 
generally should be of the same data type (e.g., G.711) and 
have the same data rate (e.g., 64 Kbytes/sec). Alternatively, 
the media streams may have different data types or data 
rates, as long as the receiving gateway is capable of decod- 
ing the data transmitted to it. 

Assume that there are two separate calls, A & B, already 
in the connected state between a first gateway 902 and VRU 
901, and between VRU 901 and a second gateway 903, as 
discussed hereinabove. The application issues request 904 to 
connect A and B in media redirect mode. VRU 901, func- 
tioning as an MC, sends Multipoint Conference Indication 
906 to gateway 902 for call A, putting A into conference 
mode. Likewise, VRU 901 sends Multipoint Conference 
Indication 907 to gateway 903 for call B, putting B into 
conference mode. 

VRU 901 then executes the steps to redirect A's RTP 
media stream. VRU 901 sends Communication Mode Com- 
mand 908 to instruct gateway 902 about a new multicasting 
address for Call A In response, gateway 902 closes the 
current (previously opened) outgoing logical channel for 
Call A with VRU 901, and issues the CloseLogicalChannel 
message 909 to VRU 901. VRU 901 acknowledges the 
closing of the current outgoing channel for Call Aby sending 
the Close LogicalChannelAck message 910 to gateway 902. 
Then gateway 902 opens a new outgoing channel for Call A 
and issues OpenLogicalChannel message 911 to VRU 901. 
VRU 901 acknowledges the opening of the new logical 
channel for Call A with gateway 902 and sends OpenLogi- 
calChannelAck message 912, which contains call B's IP and 
RTP address, to gateway 902, thus redirecting Call A's 
media stream to gateway 903. 
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This sequence is repeated for Call B with gateway 903 in 
order to redirect Call B's media stream. VRU 901 sends 
Communication Mode Command 913 to instruct gateway 
903 about a new multicasting address for Call B. In 
response, gateway 903 closes the current (previously 
opened) outgoing logical channel for Call B with VRU 901, 
and issues the CloseLogicalChannel message 914 to VRU 
901. VRU 901 acknowledges the closing of the current 
outgoing channel for Call B by sending the CloseLogical- 
ChannelAck message 915 to gateway 903. Then gateway 
903 opens a new outgoing channel for Call B and issues 
OpenLogicalChannel message 916 to VRU 901. VRU 901 
acknowledges the opening of the new logical channel for 
Call B with gateway 903 and sends OpenLogicalChan- 
nelAck message 917, which contains call A's IP and RTP 
address, to gateway 903, thus redirecting Call B's media 
stream to gateway 902. Upon completion of the media 
redirection, a media redirect done message 918 is sent to the 
application indicating that the media redirect is complete. 

Once the call is completed, or for another reason, the 
application may issue request 924 that the redirected media 
streams be torn down. After tearing down the RTP streams, 
VRU 921 may either command gateways 922 and 923 to tear 
down the call controls, or VRU 921 may command gateways 
922 and 923 to set up new RTP sessions with VRU 921, 
similar to the structure that existed before the media redi- 
rection. To illustrate the latter option, and with reference to 
message protocol 920 in FIG. 6, assume that the media 
redirection illustrated in FIG. 5 has already taken place, and 
that the media streams are set up directly between gateway 
922 and gateway 923 for Calls A and B. 

VRU 921 first executes the steps to tear down Call A's 
redirected RTP media stream. VRU 921 sends Communi- 
cation Mode Command 925 to instruct gateway 922 about a 
new multicasting address for Call A. In response, gateway 
922 closes the current (previously directed to gateway 923) 
outgoing logical channel for Call A, and issues the Close- 
LogicalChannel message 926 to VRU 921. VRU 921 
acknowledges the closing of the current outgoing channel 
for Call Aby sending the CloseLogicalChannelAck message 
927 to gateway 922. Then gateway 922 opens a new 
outgoing channel for Call A and issues OpenLogicalChannel 
message 928 to VRU 921. VRU 921 acknowledges the 
opening of the new logical channel for Call A with gateway 
922 and sends OpenLogicalChannelAck message 929, 
which contains the IP and RTP address of VRU 921, to 
gateway 922, thus redirecting Call A* s media stream to VRU 
921. VRU 921 sends End Multipoint Conference message 
930 to gateway 922 to end the conference mode with Call A 
reverting to a connected state with VRU 921. 

This sequence is repeated for Call B with gateway 923 in 
order to tear down Call B's redirected RTP media stream. 
VRU 921 sends Communication Mode Command 931 to 
instruct gateway 923 about a new multicasting address for 
Call B. In response, gateway 923 closes the current 
(previously directed to gateway 922) outgoing logical chan- 
nel for Call B, and issues the CloseLogicalChannel message 
932 to VRU 921. VRU 921 acknowledges the closing of the 
current outgoing channel for Call B by sending the Close- 
LogicalChanneLAck message 933 to gateway 923. Then 
gateway 923 opens a new outgoing channel for Call B and 
issues OpenLogicalChannel message 934 to VRU 921. VRU 
921 acknowledges the opening of the new logical channel 
for Call B with gateway 923 and sends OpenLogicalChan- 
nelAck message 935, which contains the IP and RTP address 
of VRU 921, to gateway 923, thus redirecting Call B's 
media stream to VRU 921. VRU 921 sends End Multipoint 
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Conference message 936 to gateway 923 to end the confer- 
ence mode with Call B reverting to a connected state with 
VRU 921. Upon completion of the media redirection tear 
down, a media redirect disconnect done message 937 is sent 
to the application indicating that the media redirect tear 5 
down is complete. 

In these preferred embodiments, all message protocols 
generally are already available in the H.323 specification, so 
custom modifications to the gateways are not required, 
although the gateways generally should be compliant with 1Q 
the relevant sections in the H.323 specification. Upon 
completion of the call, the redirected media streams may be 
torn down in accordance with the H.323 specification. 

Other embodiments may require some custom function- 
ality to be implemented in the gateways for redirection of the 1 5 
media streams. In accordance with another preferred 
embodiment of the present invention, FIG. 7 illustrates a 
message protocol for redirecting media using Userlnputln- 
dication messages, and FIG. 8 illustrates an associated 
message protocol for tearing down the redirected media 2Q 
streams using Userlnputlndication messages. To implement 
this embodiment, the gateways generally must be pro- 
grammed to respond to special Userlnputlndication mes- 
sages from the VRU. Because the RTP protocol generally is 
carried over the UDP, and is not associated with the H.245 ^ 
call context, and because the gateway software does not use 
the IP address of the call for the RTP media stream, the 
system can specify different IP addresses and UDP ports to 
separate the RTP streams from the call control. The VRU 
may instruct the gateways to keep the dynamic UDP ports 3Q 
valid by using Userlnputlndication messages. In addition, 
the VRU may send a Userlnputlndication message to bring 
back the redirected media streams to have the RTP session 
established as before the media redirection. 

In this embodiment, the message protocol comprises the 35 
following: 

<Media Redirect Attention> <Media Redirect Command> 
<,> <DstIpAddress> <,><DstRtpUdpAddress> <,> 
<DstRtcpUdpAddress> <,> <SrcIpAddress> 
<,><SrcRtpUdpAddress> <,> <SrcRtcpUdpAddress> 4Q 
<,> <RtpSessionMode> 
All values are in the ASCII Hex representations. The 
Media Redirect Attention Command is generally referred to 
as a "bang," and is denned as 

<Media Redirect Attentions"!" 4S 
The Media Redirect Attention message signals to the 
gateway that a Media Redirect Command is following. The 
gateway then interprets the subsequent information as part 
of the media redirect protocol instead of as some type of 
DTMF message. There are two primary Media Redirect 50 
Commands: DROP_RTP and NEW_RTP, wherein: 

<Media Redirect Command>="9" for DROP_RTP Com- 
mand 

<Media Redirect Command>="5" for NEW _RTP Com- 
mand 55 

Referring to message protocol 940 in FIG. 7, assume that 
there are two separate calls, A & B, already set up between 
a first gateway 946 and the VRU, and between the VRU and 
a second gateway 948, as discussed hereinabove. VRU 
application 942 initiates media redirection by issuing media 60 
redirect command 950 to VoIP driver 944 inside the VRU. 
VoIP driver 944 then handles the detailed protocol of send- 
ing Media Redirect Messages to the gateways to accomplish 
the media redirection. First VoIP driver 944 sends DROP_ 
RTP A Message 952 to gateway 946 to command gateway 65 
946 to drop the media stream between gateway 946 and the 
VRU. Similarly, VoIP driver 944 sends DROP_RTP B 



Message 954 to gateway 948 to command gateway 948 to 
drop the media stream between gateway 948 and the VRU. 
VoIP driver 944 then sends NEW_RTP A-to-B Message 956 
to gateway 946 to establish the new media stream from 
gateway 946 to gateway 948. Similarly, VoIP driver 944 then 
sends NEW_RTP B-to-A Message 958 to gateway 948 to 
establish the new media stream from gateway 948 to gate- 
way 946. Finally, VoIP driver 944 sends media redirect 
complete message 959 back to VRU application 942 to 
indicate completion of the media redirection. As previously 
discussed, only the media streams are redirected, and the 
H.245-G.931 call control structures between the VRU and 
each gateway are left intact. 

Once the call is complete, or for another reason, the VRU 
may command the gateways to tear down the redirected 
media streams. After the media streams are torn down, the 
VRU may either command the gateways to tear down the 
call controls, or the VRU may command the gateways to set 
up new RTP sessions with the VRU, similar to the structure 
that existed before the media redirection. To illustrate the 
latter option, and with reference to message protocol 960 in 
FIG. 8, assume that the media redirection illustrated in FIG. 
6 has already taken place, and that the media streams are set 
up directly between gateway 966 and gateway 968. VRU 
application 962 initiates media redirection tear down by 
issuing media redirect tear down command 970 to VoIP 
driver 964 inside the VRU. VoIP driver 964 then handles the 
detailed protocol of sending Media Redirect Messages to the 
gateways to accomplish the media redirection tear down. 
First VoIP driver 964 sends DROP_RTP A-to-B Message 
972 to gateway 966 to command gateway 966 to drop the 
media stream from gateway 966 to gateway 968. Similarly, 
VoIP driver 964 sends DROP_RTP B-to-A Message 974 to 
gateway 968 to command gateway 968 to drop the media 
stream from gateway 968 to gateway 966. VoIP driver 964 
then sends NEW_RTP A-to- VRU Message 976 to gateway 
966 to reestablish the media stream from gateway 966 to the 
VRU. Similarly, VoIP driver 964 then sends NEW_RTP 
B-to-VRU Message 978 to gateway 968 to reestablish the 
media stream from gateway 968 to the VRU. Finally, VoIP 
driver 964 sends media redirect complete message 980 back 
to VRU application 962 to indicate completion of the media 
redirection tear down. As previously discussed, only the 
media streams are reestablished between the VRU and the 
gateways, and the H.245- G. 931 call control structures 
between the VRU and each gateway continue to remain as 
they were originally set up. 

Another specific media redirection implementation may 
be to use functions (e.g., CallJoin and CalUnvite) described 
in section 8.4.3 of the H.323 specification, entitled Ad-hoc 
conference expansion. While preliminary laboratory tests 
thus far have not allowed the exchange of voice data 
between call A and call B in the laboratory, a conference in 
between call A and call B has successfully been established. 
Therefore the Ad-hoc conference expansion functions may 
also represent a viable approach for media redirection. 

Depending on the specific application, a packet VRU 
according to the present invention may provide many dif- 
ferent enhanced services to users linked to the network, 
including voice messaging, email (containing at least one of: 
voice, audio and data), automated collect calling, interna- 
tional callback, prepaid calling card, postpaid calling card, 
store & forward, one number, find me, follow me, 800/900 
service, automated customer service, automated agents or 
attendants, enhanced fax, voice activated dialing, prepaid & 
postpaid wireless, conferencing, and other enhanced ser- 
vices. These services may be voice services, similar to the 
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services provided by synchronous VRUs, or may be multi- of which are intended within the scope of the present 

media services, capable of handling any combination of invention. For example, devices with wireless, satellite or 

voice, video and data (e.g., text). cable interfaces may be linked to the packet network, and 

It is understood that a specific implementation of a packet may communicate with and utilize the enhanced services of 

VRU may be accomplished in hardware or software or a 5 me P ac ^et VRU. 

combination thereof. It is further understood that packet Furthermore, while a PSTN may be shown as being 

routing controlled by the packet VRU generally enables into different sections in the figures for ease of 

point-to-point connections, multi-party conferencing, and explanation, it is understood that the se^oiis may all be part 

broadcast as required. In this way, for example, large con- of .fTf "T^rZ ^ m wlth t Som H e areaS 
» i, i. I* j r j c *i_ ? « accessible locally with little or no variable cost, and some 
ferencecdls maybe enab ed,ora feed fr^ 10 ^ accessibl / b { Stance at a variai ; ie mi ^ 
may be broadcast to facilitate a radio talk show. It is further ^ mQn {Q ^ ^ fixed CQSt access 
understood that consistent with the present invention, the Although the present invention and its advantages have 
packet VRU may be either collocated with a gateway (on the been described in detail, it should be understood that various 
packet side) or a gatekeeper, or distant therefrom. While not changes, substitutions and alterations can be made herein 
a preferred embodiment in the long term, a packet VRU may 15 without departing from the spirit and scope of the invention 
also comprise a switched interface to, for example, a PSTN. as defined by the appended claims. Moreover, the scope of 
It is further understood that the exact order of many of the the present application is not intended to be limited to the 
steps outlined in the methods discussed herein may be particular embodiments of the process, machine, 
altered, and such alterations are intended to be within the manufacture, composition of matter, means, methods and 
scope of the present invention. For example, redirected RTP 20 steps described in the specification. As one of ordinary skill 
streams may be set up before or after the original RTP in the art will readily appreciate from the disclosure of the 
streams are torn down. As another example, when connect- present invention, processes, machines, manufacture, com- 
ing multiple parties, all the H.323 calls may first be set up, positions of matter, means, methods, or steps, presently 
followed by the setup of the RTP streams, or each H.323 call existing or later to be developed that perform substantially 
and RTP stream pair for a specific party may be set up, 25 the same function or achieve substantially the same result as 
followed by the setup for another party. As another example, the corresponding embodiments described herein may be 
more than one command may be sent before waiting for the uUllz ^ fording to the present invention. A^ordmgly, the 

« a Ae . nitnt L„ appended claims are mtended to include within their scope 

corresponding acknowledge return message. As yet another r 

i r>Tn * u i ♦ i j* * a such processes, machines, manufacture, compositions or 

example, one RTP stream may be completely redirected, ^ r _, , 

then the other RTP stream redirected, or commands may be 30 matter means, methods, or steps. 

^Vnat is claimed is - 

alternated in some manner in redirecting the RTP streams. In . . t , . " . , 

, - j . « 1. A method for redirecting media in an asynchronous 

addition, some of the specific commands, especially com- , * * i i_ * u i * ,w 

mands in a custom implementation (e.g., ! , 5 and 9), may be P a * et ° etwo * b \* ^ m asynchronously connected to 

changed and still be within the scope of the present inven- said packet network, sard method compnsmg: 

^ on 3S establishing a first call between a first device and said 

In yet another alternative embodiment, for some applica- s y stem via said P acket network > wherein ^ cal1 

tions it may be usefull to direct the control calls to the packet comprises a first call control structure and a first media 

VRU as discussed hereinabove, but to immediately direct stream; 

the media stream to the destination, instead of first directing establishing a second call between said system and a 

the media stream to the VRU and then redirecting it to the 40 second device via said packet network, wherein said 

destination second call comprises a second call control structure 

It is further understood that while the primary standard and a second media stream; 

discussed above is H.323, other standards may be present on signaling said first device to redirect said first media 

a packet network and are mtended to be within the scope of stream to said second device; and 

the present invention. For example, Session Initiation Pro- 45 signaling said second device to redirect said second media 

tocol ("SIP"), Simple Gateway Control Protocol ("SGCP") stream to said first device, wherein said first and second 

and Media Gateway Controller Protocol ("MEGACO") may call control structures are not redirected away from said 

alternatively be used to implement media redirection. Each system, and said system does not receive said media 

standard has somewhat different functionality, and each has while said media streams are redirected, 

certain advantages and disadvantages with respect to other 50 2. The method of claim 1, wherein said first and second 

the standards. devices are network gateways. 

It is further understood that while the core functionality of 3. The method of claim 1, wherein at least one of said first 

a packet VRU is enhancing voice communications, it may be and second devices is an Internet Protocol phone, 

possible for any device connected to the packet network may 4. The method of claim 1, wherein said establishing said 

communicate with and utilize the enhanced services of the 55 first call comprises receiving said first call from said first 

packet VRU (e.g., a fax machine, data modem or telephone device. 

via a gateway, or computers or other terminals connected to 5. The method of claim 1, wherein said establishing said 

the packet network and executing H.323 protocols). It is second call comprises initiating said second call with said 

further understood that, to take advantage of the present second device. 

invention, a computer user typically requires a multimedia- 60 6. The method of claim 5, wherein said second call is 

grade computer, including speakers, sound card, micro- initiated in response to information provided in said first 

phone and fall duplex voice-enabling software. call. 

Alternatively, the computer may also include a video input 7. The method of claim 1, wherein said first and second 

useful, e.g., in video conferencing. Alternatively, the com- calls are H.323 standard calls. 

puter user may use a lower capability computer in combi- 65 8. The method of claim 7, wherein said first and second 

nation with a traditional telephone. It is further understood call control structures each comprise G.931 standard call 

that there are many ways to connect to a packet network, all signaling and H.245 standard call control. 
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9. The method of claim 7, wherein said media streams are 
real-time protocol media streams. 

10. The method of claim 7, wherein said media streams 
are real-time control protocol media streams. 

11. The method of claim 1, wherein said packet network 5 
is the Internet. 

12. The method of claim 1, wherein said media is voice. 

13. The method of claim 1, wherein said media is selected 
from the group consisting of: voice, video, multimedia, and 
combinations thereof. 10 

14. The method of claim 1, wherein said first and second 
media streams comprise the same data type and data rate. 

15. The method of claim 1, wherein said first and second 
media streams comprise different data types and data rates. 

16. The method of claim 1, wherein call context for said 15 
first and second calls is retained by said system. 

17. The method of claim 1, further comprising: 
tearing down said first media stream redirected to said 

second device; 

tearing down said second media stream redirected to said 20 
first device; 

tearing down said second call control structure; and 
reestablishing said first media stream between said first 
device and said system, wherein said first call is recon- ^ 
nected as before said redirect of said first media stream. 

18. The method of claim 17, further comprising: 
establishing a third call between said system and a third 

device via said packet network, wherein said third call 
comprises a third call control structure and a third 30 
media stream; 

signaling said first device to redirect said first media 

stream to said third device; and 
signaling said third device to redirect said third media 

stream to said first device; wherein said first and third 35 

call control structures are not redirected away from said 

system. 

19. The method of claim 18, wherein said tearing down of 
said of said first and second media streams and said second 
call control structure are in response to a user input indica- 40 
tion message received from said first device. 

20. The method of claim 1, further comprising: 
tearing down said first media stream redirected to said 

second device; 

tearing down said second media stream redirected to said 45 
first device; 

tearing down said first call control structure; and 
tearing down said second call control structure. 

21. The method of claim 1, further comprising: 5Q 
tearing down said first media stream redirected to said 

second device; 
tearing down said second media stream redirected to said 
first device; 

reestablishing said first media stream between said first 55 
device and said system, wherein said first call is recon- 
nected as before said redirect of said first media stream; 
and 

reestablishing said second media stream between said 
system and said second device, wherein said second eo 
call is reconnected as before said redirect of said 
second media stream. 

22. The method of claim 1, further comprising: 
establishing a third call between said system and a third 

device via said packet network, wherein said third call 65 
comprises a third call control structure and a third 
media stream; 
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signaling said first device to replicate said first media 
stream to send data to said third device in addition to 
said second device; 
signaling said second device to replicate said second 
media stream to send data to said third device in 
addition to said first device; 
signaling said third device to redirect said third media 

stream to said first device; and 
signaling said third device to replicate said third media 
stream to send data to said second device in addition to 
said first device, wherein said third call control struc- 
ture is not redirected away from said system. 

23. The method of claim 1, wherein user input indication 
messages are transmitted out-of-band from said media 
streams. 

24. The method of claim 23, wherein said user input 
indication messages are transmitted in at least one of said 
call control structures. 

25. The method of claim 23, wherein said user input 
indication messages comprise dual tone multiple frequency 
(DTMF) signal messages. 

26. The method of claim 23, wherein said user input 
indication messages are generated by said first device. 

27. The method of claim 23, further comprising: 

receiving said user input indication messages from said 
first device. 

28. The method of claim 27, further comprising: 
forwarding said user input indication messages to said 

second device. 

29. The method of claim 1, wherein said system is a 
packet voice response unit. 

30. The system of claim 29, wherein said packet voice 
response unit provides an enhanced service selected from 
the group consisting of: prepaid calling card service, post- 
paid calling card service, collect calling service, interna- 
tional callback service, one number service, voice activated 
dialing service, conferencing service, and combinations 
thereof. 

31. The method of claim 1, wherein said system is 
asynchronously connected to said packet network via an 
Ethernet connection. 

32. A system for redirecting media in an asynchronous 
packet network, said system comprising: 

an asynchronous interface to said packet network; 

means for establishing a first call with a first device via 
said packet network, wherein said first call comprises a 
first call control structure and a first media stream; 

means for establishing a second call with a second device 
via said packet network, wherein said second call 
comprises a second call control structure and a second 
media stream; 

means for signaling said first device to redirect said first 
media stream to said second device; and 

means for signaling said second device to redirect said 
second media stream to said first device, wherein said 
first and second call control structures are not redi- 
rected away from said system, and said system does not 
receive said media while said media streams are redi- 
rected. 

33. The system of claim 32, wherein said asynchronous 
interface is an Ethernet connection. 

34. The system of claim 32, wherein said first and second 
devices are network gateways. 

35. The system of claim 32, wherein at least one of said 
first and second devices is an Internet Protocol (IP) phone. 
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36. The system of claim 32, wherein said means for 
establishing said first call comprises means for receiving 
said first call from said first device. 

37. The system of claim 32, wherein said means for 
establishing said second call comprises means for initiating 5 
said second call with said second device. 

38. The method of claim 37, wherein said second call is 
initiated in response to information provided in said first 
call. 

39. The system of claim 32, wherein said first and second 10 
calls are H.323 standard calls. 

40. The system of claim 39, wherein said first and second 
call control structures each comprise G.931 standard call 
signaling and H.245 standard call control. 15 

41. The system of claim 40, wherein said media streams 
are real-time protocol media streams. 

42. The system of claim 40, wherein said media streams 
are real-time control protocol media streams. 

43. The system of claim 32, wherein said packet network 2 o 
is the Internet. 

44. The system of claim 32, wherein said media is voice. 

45. The system of claim 32, wherein said media is 
selected from the group consisting of: voice, video, 
multimedia, and combinations thereof. 25 

46. The system of claim 32, wherein said first and second 
media streams comprise the same data type and data rate. 

47. The system of claim 32, wherein said first and second 
media streams comprise different data types and data rates. 

48. The system of claim 32, wherein call context for said 30 
first and second calls is retained by said system. 

49. The system of claim 32, further comprising: 
means for tearing down said first media stream redirected 

to said second device; 
means for tearing down said second media stream redi- 35 

reeled to said first device; 
means for tearing down said second call control structure; 

and 

means for reestablishing said first media stream between ^ 
said first device and said system, wherein said first call 
is reconnected as before said redirect of said first media 
stream. 

50. The system of claim 49, further comprising: 

means for establishing a third call between said system 45 
and a third device via said packet network, wherein said 
third call comprises a third call control structure and a 
third media stream; 

means for signaling said first device to redirect said first 
media stream to said third device; and 50 

means for signaling said third device to redirect said third 
media stream to said first device; wherein said first and 
third call control structures are not redirected away 
from said system. 

51. The system of claim 50, wherein said means for 55 
tearing down of said of said first and second media streams 
and said second call control structure respond to a user input 
indication message received from said first device. 

52. The system of claim 32, further comprising: 

means for tearing down said first media stream redirected 60 
to said second device; 

means for tearing down said second media stream redi- 
rected to said first device; 

means for tearing down said first call control structure; 65 
and 

means for tearing down said second call control structure. 
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53. The system of claim 32, further comprising: 
means for tearing down said first media stream redirected 

to said second device; 

means for tearing down said second media stream redi- 
rected to said first device; 

means for reestablishing said first media stream between 
said first device and said system, wherein said first call 
is reconnected as before said redirect of said first media 
stream; and 

means for reestablishing said second media stream 
between said system and said second device, wherein 
said second call is reconnected as before said redirect 
of said second media stream. 

54. The system of claim 32, further comprising: 
means for establishing a third call between said system 

and a third device via said packet network, wherein said 

third call comprises a third call control structure and a 

third media stream; 
means for signaling said first device to replicate said first 

media stream to send data to said third device in 

addition to said second device; 
means for signaling said second device to replicate said 

second media stream to send data to said third device 

in addition to said first device; 
means for signaling said third device to redirect said third 

media stream to said first device; and 
means for signaling said third device to replicate said 

third media stream to send data to said second device 

in addition to said first device, wherein said third call 

control structure is not redirected away from said 

system. 

55. The system of claim 32, wherein user input indication 
messages are transmitted out-of-band from said media 
streams. 

56. The system of claim 55, wherein said user input 
indication messages are transmitted in at least one of said 
call control structures. 

57. The system of claim 55, wherein said user input 
indication messages comprise dual tone multiple frequency 
(DTMF) signal messages. 

58. The system of claim 55, wherein said user input 
indication messages are generated by said first device. 

59. The system of claim 55, further comprising: 
means for receiving said user input indication messages 

from said first device. 

60. The system of claim 59, further comprising: 
means for forwarding said user input indication messages 

to said second device. 

61. The system of claim 32, wherein said system is a 
packet voice response unit. 

62. The system of claim 61, wherein said packet voice 
response unit provides an enhanced service selected from 
the group consisting of: prepaid calling card service, post- 
paid calling card service, collect calling service, interna- 
tional callback service, one number service, voice activated 
dialing service, conferencing service, and combinations 
thereof. 

63. A computer program product having a computer 
readable medium with computer program logic recorded 
thereon for use in a system asynchronously connected to a 
packet network for redirecting media in said asynchronous 
packet network, said computer program product comprising: 

code for establishing a first call with a first device via said 
packet network, wherein said first call comprises a first 
call control structure and a first media stream; 
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code for establishing a second call with a second device 
via said packet network, wherein said second call 
comprises a second call control structure and a second 
media stream; 

code for signaling said first device to redirect said first 5 
media stream to said second device; and 

code for signaling said second device to redirect said 
second media stream to said first device, wherein said 
first and second call control structures are not redi- 
rected away from said system, and said system does not 10 
receive said media while said media streams are redi- 
rected. 

64. The computer program product of claim 63, wherein 
said system is a packet voice response unit. 

65. The computer program product of claim 64, wherein 15 
said packet voice response unit provides an enhanced ser- 
vice selected from the group consisting of: prepaid calling 
card service, postpaid calling card service, collect calling 
service, international callback service, one number service, 
voice activated dialing service, conferencing service, and 20 
combinations thereof. 

66. The computer program product of claim 63, wherein 
said system is asynchronously connect to said packet net- 
work via an Ethernet connection. 

67. The computer program product of claim 63, wherein 25 
said first and second devices are network gateways. 

68. The computer program product of claim 63, wherein 
at least one of said first and second devices is an Internet 
Protocol (IP) phone. 

69. The computer program product of claim 63, wherein 30 
said code for establishing said first call comprises code for 
receiving said first call from said first device. 

70. The computer program product of claim 63, wherein 
said code for establishing said second call comprises code 
for initiating said second call with said second device. 35 

71. The method of claim 70, wherein said second call is 
initiated in response to information provided in said first 
call. 

72. The computer program product of claim 63, wherein 
said first and second calls are H.323 standard calls. 40 

73. The computer program product of claim 72, wherein 
said first and second call control structures each comprise 
G.931 standard call signaling and H.245 standard call con- 
trol. 

74. The computer program product of claim 72, wherein 45 
said media streams are real-time protocol media streams. 

75. The computer program product of claim 72, wherein 
said media streams are real-time control protocol media 
streams. 

76. The computer program product of claim 63, wherein 50 
said packet network is the Internet. 

77. The computer program product of claim 63, wherein 
said media is voice. 

78. The computer program product of claim 63, wherein 
said media is selected from the group consisting of: voice, 55 
video, multimedia, and combinations thereof. 

79. The computer program product of claim 63, wherein 
said first and second media streams comprise the same data 
type and data rate. 

80. The computer program product of claim 63, wherein 60 
said first and second media streams comprise different data 
types and data rates. 

81. The computer program product of claim 63, wherein 
call context for said first and second calls is retained by said 
system. 65 

82. The computer program product of claim 63, further 
comprising: 
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code for tearing down said first media stream redirected to 
said second device; 

code for tearing down said second media stream redi- 
rected to said first device; 

code for tearing down said second call control structure; 
and 

code for reestablishing said first media stream between 
said first device and said system, wherein said first call 
is reconnected as before said redirect of said first media 
stream. 

83. The computer program product of claim 82, further 
comprising: 

code for establishing a third call between said system and 
a third device via said packet network, wherein said 
third call comprises a third call control structure and a 
third media stream; 

code for signaling said first device to redirect said first 
media stream to said third device; and 

code for signaling said third device to redirect said third 
media stream to said first device; wherein said first and 
third call control structures are not redirected away 
from said system. 

84. The computer program product of claim 83, wherein 
said code for tearing down of said of said first and second 
media streams and said second call control structure respond 
to a user input indication message received from said first 
device. 

85. The computer program product of claim 63, further 
comprising: 

code for tearing down said first media stream redirected to 
said second device; 

code for tearing down said second media stream redi- 
rected to said first device; 

code for tearing down said first call control structure; and 

code for tearing down said second call control structure. 

86. The computer program product of claim 63, further 
comprising: 

code for tearing down said first media stream redirected to 
said second device; 

code for tearing down said second media stream redi- 
rected to said first device; 

code for reestablishing said first media stream between 
said first device and said system, wherein said first call 
is reconnected as before said redirect of said first media 
stream; and 

code for reestablishing said second media stream between 
said system and said second device, wherein said 
second call is reconnected as before said redirect of 
said second media stream. 

87. The computer program product of claim 63, further 
comprising: 

code for establishing a third call between said system and 

a third device via said packet network, wherein said 

third call comprises a third call control structure and a 

third media stream; 
code for signaling said first device to replicate said first 

media stream to send data to said third device in 

addition to said second device; 
code for signaling said second device to replicate said 

second media stream to send data to said third device 

in addition to said first device; 
code for signaling said third device to redirect said third 

media stream to said first device; and 
code for signaling said third device to replicate said third 

media stream to send data to said second device in 
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addition to said first device, wherein said third call 105. The system of claim 103, wherein said user input 

control structure is not redirected away from said indication messages comprise dual tone multiple frequency 

system. (DTMF) signal messages. 

88. The computer program product of claim 63, herein 106. The system of claim 103, wherein said user input 
user input indication messages are transmitted out-of-band 5 indication messages are generated one of said devices, 
from said media streams. 107. The system of claim 94, wherein said system is a 

89. The computer program product of claim 88, wherein packet voice response unit. 

said user input indication messages are transmitted in at least 108. The system of claim 107, wherein said packet voice 

one of said call control structures. response unit provides an enhanced service selected from 

90. The computer program product of claim 88, wherein the group consisting of: prepaid calling card service, post- 
said user input indication messages comprise dual tone paid calling card service, collect calling service, interna- 
multiple frequency (DTMF) signal messages. tional callback service, one number service, voice activated 

91. The computer program product of claim 88, wherein dialing service, conferencing service, and combinations 
said user input indication messages are generated by said thereof. 

first device. 109. The system of claim 94, wherein said asynchronous 

92. The computer program product of claim 88, further 15 interface is an Ethernet connection. 

comprising: 110. The system of claim 94, wherein said devices are 

code for receiving said user input indication messages network gateways, 

from said first device. 111. The system of claim 94, wherein at least one of said 

93. The computer program product of claim 92, further devices is an Internet Protocol (IP) phone, 
comprising: 20 112. A method for redirecting media in an asynchronous 

code for forwarding said user input indication messages to packet network by a system asynchronously connected to 

said second device. sa id packet network, said method comprising: 

94. A system for redirecting media in an asynchronous establishing a first call between a first device and said 
packet network, said system comprising: system via said packet network, wherein said first call 

an asynchronous interface to said packet network; 25 comprises a first call control structure and a first media 

a call control server, wherein said call control server sets stream; 

up call control structures to communicate with devices establishing a second call between said system and a 

in said packet network via said asynchronous interface second device via said packet network, wherein said 

for controlling media streams from and to said devices; second call comprises a second call control structure 

a voice media server communicating with said call control 30 a second media stream; 

server, wherein said call control server uses said call signaling said first device to redirect said first media 

control structures to establish media streams between stream to said second device; and 

said devices and said voice media server via said signaling said second device to redirect said second media 

asynchronous interface; and stream to said first device, wherein said first and second 

an application server communicating with said call con- 35 call control structures are not redirected away from said 

trol server and said voice media server, wherein said system, and said system continues to receive a copy of 

application server instructs said call control server to said media streams while said media streams are redi- 

redirect said media streams to be transmitted directly rected. 

between said devices without passing through said 113. The method of claim 112, wherein said first and 

voice media server, and wherein said call control 40 second devices are network gateways, 

structures are retained between said devices and said 114. The method of claim 112, wherein at least one of said 

voice media server, and said voice media server does first and second devices is an Internet Protocol phone, 

not receive said media while said media streams are 115. The method of claim 112, wherein said establishing 

redirected. said first call comprises receiving said first call from said 

95. The system of claim 94, wherein said call control 45 first device. 

structures each comprise G.931 standard call signaling and 116. The method of claim 112, wherein said establishing 

H.245 standard call control. said second call comprises initiating said second call with 

96. The system of claim 94, wherein said media streams said second device. 

are real-time protocol media streams. 117. The method of claim 116, wherein said second call 

97. The system of claim 94, wherein said media streams 50 is initiated in response to information provided in said first 
are real-time control protocol media streams. call. 

98. The system of claim 94, wherein said packet network 118. The method of claim 112, wherein said first and 
is the Internet. second calls are H.323 standard calls. 

99. The system of claim 94, wherein said media is voice. 119. The method of claim 118, wherein said first and 

100. The system of claim 94, wherein said media is 55 second call control structures each comprise G.931 standard 
selected from the group consisting of: voice, video, call signaling and H.245 standard call control, 
multimedia, and combinations thereof. 120. The method of claim 118, wherein said media 

101. The system of claim 94, wherein said first and second streams are real-time protocol media streams. 

media streams comprise the same data type and data rate. 121. The method of claim 118, wherein said media 

102. The system of claim 94, wherein said first and second 60 streams are real-time control protocol media streams, 
media streams comprise different data types and data rates. 122. The method of claim 112, wherein said packet 

103. The system of claim 94, wherein user input indica- network is the Internet. 

tion messages are transmitted out-of-band from said media 123. The method of claim 112, wherein said media is 

streams. voice. 

104. The system of claim 103, wherein said user input 65 124. The method of claim 112, wherein said media is 
indication messages are transmitted in at least one of said selected from the group consisting of: voice, video, 
call control structures. multimedia, and combinations thereof. 
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125. The method of claim 112, wherein said first and 
second media streams comprise the same data type and data 
rate. 

126. The method of claim 112, wherein said first and 
second media streams comprise different data types and data 
rates. 

127. The method of claim 112, wherein call context for 
said first and second calls is retained by said system. 

128. The method of claim 112, further comprising: 
tearing down said first media stream redirected to said 

second device; 
tearing down said second media stream redirected to said 
first device; 

tearing down said second call control structure; and 
reestablishing said first media stream between said first 
device and said system, wherein said first call is recon- 
nected as before said redirect of said first media stream. 

129. The method of claim 128, further comprising: 
establishing a third call between said system and a third 

device via said packet network, wherein said third call 
comprises a third call control structure and a third 
media stream; 

signaling said first device to redirect said first media 

stream to said third device; and 
signaling said third device to redirect said third media 

stream to said first device; wherein said first and third 

call control structures are not redirected away from said 

system. 

130. The method of claim 129, wherein said tearing down 
of said of said first and second media streams and said 
second call control structure are in response to a user input 
indication message received from said first device. 

131. The method of claim 112, further comprising: 
tearing down said first media stream redirected to said 

second device; 
tearing down said second media stream redirected to said 
first device; 

tearing down said first call control structure; and 
tearing down said second call control structure. 

132. The method of claim 112, further comprising: 
tearing down said first media stream redirected to said 

second device; 
tearing down said second media stream redirected to said 
first device; 

reestablishing said first media stream between said first 
device and said system, wherein said first call is recon- 
nected as before said redirect of said first media stream; 
and 

reestablishing said second media stream between said 
system and said second device, wherein said second 
call is reconnected as before said redirect of said 
second media stream. 

133. The method of claim 112, further comprising: 
establishing a third call between said system and a third 

device via said packet network, whereio said third call 
comprises a third call control structure and a third 
media stream; 

signaling said first device to replicate said first media 

stream to send data to said third device in addition to 

said second device; 
signaling said second device to replicate said second 

media stream to send data to said third device in 

addition to said first device; 
signaling said third device to redirect said third media 

stream to said first device; and 
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signaling said third device to replicate said third media 
stream to send data to said second device in addition to 
said first device, wherein said third call control struc- 
ture is not redirected away from said system. 

134. The method of claim 112, wherein user input indi- 
cation messages are transmitted out-of-band from said 
media streams. 

135. The method of claim 134, wherein said user input 
indication messages are transmitted in at least one of said 
call control structures. 

136. The method of claim 134, wherein said user input 
indication messages comprise dual tone multiple frequency 
(DTMF) signal messages. 

137. The method of claim 134, wherein said user input 
indication messages are generated by said first device. 

138. The method of claim 134, further comprising: 
receiving said user input indication messages from said 

first device. 

139. The method of claim 138, further comprising: 
forwarding said user input indication messages to said 

second device. 

140. The method of claim 112, wherein said system is a 
packet voice response unit. 

141. The system of claim 140, wherein said packet voice 
response unit provides an enhanced service selected from 
the group consisting of: prepaid calling card service, post- 
paid calling card service, collect calling service, interna- 
tional callback service, one number service, voice activated 
dialing service, conferencing service, and combinations 
thereof. 

142. The method of claim 112, wherein said system is 
asynchronously connected to said packet network via an 
Ethernet connection. 

143. A system for redirecting media in an asynchronous 
packet network, said system comprising: 

an asynchronous interface to said packet network; 

means for establishing a first call with a first device via 
said packet network, wherein said first call comprises a 
first call control structure and a first media stream; 

means for establishing a second call with a second device 
via said packet network, wherein said second call 
comprises a second call control structure and a second 
media stream; 

means for signaling said first device to redirect said first 
media stream to said second device; and 

means for signaling said second device to redirect said 
second media stream to said first device, wherein said 
first and second call control structures are not redi- 
rected away from said system, and said system contin- 
ues to receive a copy of said media streams while said 
media streams are redirected. 

144. The system of claim 143, wherein said first and 
second devices are network gateways. 

145. The system of claim 143, wherein at least one of said 
first and second devices is an Internet Protocol (IP) phone. 

146. The system of claim 143, wherein said means for 
establishing said first call comprises means for receiving 
said first call from said first device. 

147. The system of claim 143, wherein said means for 
establishing said second call comprises means for initiating 
said second call with said second device. 

148. The method of claim 147, wherein said second call 
is initiated in response to information provided in said first 
call. 

149. The system of claim 143, wherein said first and 
second calls are H.323 standard calls. 
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150. The system of claim 149, wherein said first and 
second call control structures each comprise G.931 standard 
call signaling and H.245 standard call control. 

151. The system of claim 150, wherein said media streams 
are real-time protocol media streams. 

152. The system of claim 150, wherein said media streams 
are real-time control protocol media streams. 

153. The system of claim 143, wherein said packet 
network is the Internet. 

154. The system of claim 143, wherein said media is 
voice. 

155. The system of claim 143, wherein said media is 
selected from the group consisting of: voice, video, 
multimedia, and combinations thereof. 

156. The system of claim 143, wherein said first and 15 
second media streams comprise the same data type and data 
rate. 

157. The system of claim 143, wherein said first and 
second media streams comprise different data types and data 
rates. 20 

158. The system of claim 143, wherein call context for 
said first and second calls is retained by said system. 

159. The system of claim 143, further comprising: 
means for tearing down said first media stream redirected 

to said second device; 

means for tearing down said second media stream redi- 
rected to said first device; 

means for tearing down said second call control structure; 
and 

means for reestablishing said first media stream between 
said first device and said system, wherein said first call 
is reconnected as before said redirect of said first media 
stream. 

160. The system of claim 159, further comprising: 
means for establishing a third call between said system 

and a third device via said packet network, wherein said 

third call comprises a third call control structure and a 

third media stream; 
means for signaling said first device to redirect said first 

media stream to said third device; and 
means for signaling said third device to redirect said third 

media stream to said first device; wherein said first and 

third call control structures are not redirected away 

from said system. 

161. The system of claim 160, wherein said means for 
tearing down of said of said first and second media streams 
and said second call control structure respond to a user input 
indication message received from said first device. 

162. The system of claim 143, further comprising: 
means for tearing down said first media stream redirected 

to said second device; 

means for tearing down said second media stream redi- 
rected to said first device; 

means for tearing down said first call control structure; 
and 

means for tearing down said second call control structure. 

163. The system of claim 143, further comprising: 
means for tearing down said first media stream redirected 60 

to said second device; 

means for tearing down said second media stream redi- 
rected to said first device; 

means for reestablishing said first media stream between 
said first device and said system, wherein said first call 65 
is reconnected as before said redirect of said first media 
stream; and 
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means for reestablishing said second media stream 
between said system and said second device, wherein 
said second call is reconnected as before said redirect 
of said second media stream. 

164. The system of claim 143, further comprising: 
means for establishing a third call between said system 

and a third device via said packet network, wherein said 

third call comprises a third call control structure and a 

third media stream; 
means for signaling said first device to replicate said first 

media stream to send data to said third device in 

addition to said second device; 
means for signaling said second device to replicate said 

second media stream to send data to said third device 

in addition to said first device; 
means for signaling said third device to redirect said third 

media stream to said first device; and 
means for signaling said third device to replicate said 

third media stream to send data to said second device 

in addition to said first device, wherein said third call 

control structure is not redirected away from said 

system. 

165. The system of claim 143, wherein user input indi- 
cation messages are transmitted out-of-band from said 
media streams. 

166. The system of claim 165, wherein said user input 
indication messages are transmitted in at least one of said 
call control structures. 

167. The system of claim 165, wherein said user input 
indication messages comprise dual tone multiple frequency 
(DTMF) signal messages. 

168. The system of claim 165, wherein said user input 
indication messages are generated by said first device. 

169. The system of claim 165, further comprising: 
means for receiving said user input indication messages 

from said first device. 

170. The system of claim 169, further comprising: 
means for forwarding said user input indication messages 

to said second device. 

171. The system of claim 143, wherein said system is a 
packet voice response unit. 

172. The system of claim 171, wherein said packet voice 
response unit provides an enhanced service selected from 
the group consisting of: prepaid calling card service, post- 
paid calling card service, collect calling service, interna- 
tional callback service, one number service, voice activated 
dialing service, conferencing service, and combinations 
thereof. 

173. The system of claim 143, wherein said asynchronous 
interface is an Ethernet connection. 

174. A computer program product having a computer 
readable medium with computer program logic recorded 
thereon for use in a system asynchronously connected to a 
packet network for redirecting media in said asynchronous 
packet network, said computer program product comprising: 

code for establishing a first call with a first device via said 
packet network, wherein said first call comprises a first 
call control structure and a first media stream; 

code for establishing a second call with a second device 
via said packet network, wherein said second call 
comprises a second call control structure and a second 
media stream; 

code for signaling said first device to redirect said first 
media stream to said second device; and 

code for signaling said second device to redirect said 
second media stream to said first device, wherein said 
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first and second call control structures are not redi- 
rected away from said system, and said system contin- 
ues to receive a copy of said media streams while said 
media streams are redirected. 

175. The computer program product of claim 174, 
wherein said first and second devices are network gateways. 

176. The computer program product of claim 174, 
wherein at least one of said first and second devices is an 
Internet Protocol (IP) phone. 

177. The computer program product of claim 174, 
wherein said code for establishing said first call comprises 
code for receiving said first call from said first device. 

178. The computer program product of claim 174, 
wherein said code for establishing said second call com- 
prises code for initiating said second call with said second 
device. 

179. The method of claim 178, wherein said second call 
is initiated in response to information provided in said first 
call. 

180. The computer program product of claim 174, 
wherein said first and second calls are H.323 standard calls. 

181. The computer program product of claim 180, 
wherein said first and second call control structures each 
comprise G.931 standard call signaling and H.245 standard 
call control. 

182. The computer program product of claim 180, 
wherein said media streams are real-time protocol media 
streams. 

183. The computer program product of claim 180, 
wherein said media streams are real-time control protocol 
media streams. 

184. The computer program product of claim 174, 
wherein said packet network is the Internet. 

185. The computer program product of claim 174, 
wherein said media is voice. 

186. The computer program product of claim 174, 
wherein said media is selected from the group consisting of: 
voice, video, multimedia, and combinations thereof. 

187. The computer program product of claim 174, 
wherein said first and second media streams comprise the 
same data type and data rate. 

188. The computer program product of claim 174, 
wherein said first and second media streams comprise dif- 
ferent data types and data rates. 

189. The computer program product of claim 174, 
wherein call context for said first and second calls is retained 
by said system. 

190. The computer program product of claim 174, further 
comprising: 

code for tearing down said first media stream redirected to 
said second device; 

code for tearing down said second media stream redi- 
rected to said first device; 

code for tearing down said second call control structure; 
and 

code for reestablishing said first media stream between 
said first device and said system, wherein said first call 
is reconnected as before said redirect of said first media 
stream. 

191. The computer program product of claim 190, further 
comprising: 

code for establishing a third call between said system and 
a third device via said packet network, wherein said 
third call comprises a third call control structure and a 
third media stream; 

code for signaling said first device to redirect said first 
media stream to said third device; and 
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code for signaling said third device to redirect said third 
media stream to said first device; wherein said first and 
third call control structures are not redirected away 
from said system. 

192. The computer program product of claim 191, 
wherein said code for tearing down of said of said first and 
second media streams and said second call control structure 
respond to a user input indicatiou message received from 
said first device. 

193. The computer program product of claim 174, further 
comprising: 

code for tearing down said first media stream redirected to 
said second device; 

code for tearing down said second media stream redi- 
rected to said first device; 

code for tearing down said first call control structure; and 

code for tearing down said second call control structure. 

194. The computer program product of claim 174, further 
comprising: 

code for tearing down said first media stream redirected to 
said second device; 

code for tearing down said second media stream redi- 
rected to said first device; 

code for reestablishing said first media stream between 
said first device and said system, wherein said first call 
is reconnected as before said redirect of said first media 
stream; and 

code for reestablishing said second media stream between 
said system and said second device, wherein said 
second call is reconnected as before said redirect of 
said second media stream. 

195. The computer program product of claim 174, further 
comprising: 

code for establishing a third call between said system and 
a third device via said packet network, wherein said 
third call comprises a third call control structure and a 
third media stream; 

code for signaling said first device to replicate said first 
media stream to send data to said third device in 
addition to said second device; 

code for signaling said second device to replicate said 
second media stream to send data to said third device 
in addition to said first device; 

code for signaling said third device to redirect said third 
media stream to said first device; and 

code for signaling said third device to replicate said third 
media stream to send data to said second device in 
addition to said first device, wherein said third call 
control structure is not redirected away from said 
system. 

196. The computer program product of claim 174, 
wherein user input indication messages are transmitted 
out-of-band from said media streams. 

197. The computer program product of claim 196, 
wherein said user input indication messages are transmitted 
in at least one of said call control structures. 

198. The computer program product of claim 196, 
wherein said user input indication messages comprise dual 
tone multiple frequency (DTMF) signal messages. 

199. The computer program product of claim 196, 
wherein said user input indication messages are generated 
by said first device. 

200. The computer program product of claim 196, further 
comprising: 

code for receiving said user input indication messages 
from said first device. 
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201. Hie computer program product of claim 200, further 
comprising: 

code for forwarding said user input indication messages to 
said second device. 

202. The computer program product of claim 174, 
wherein said system is a packet voice response unit. 

203. The computer program product of claim 202, 
wherein said packet voice response unit provides an 
enhanced service selected from the group consisting of: 
prepaid calling card service, postpaid calling card service, 
collect calling service, international callback service, one 
number service, voice activated dialing service, conferenc- 
ing service, and combinations thereof. 

204. The computer program product of claim 174, 
wherein said system is asynchronously connect to said 
packet network via an Ethernet connection. 

205. A system for redirecting media in an asynchronous 
packet network, said system comprising: 

an asynchronous interface to said packet network; 

a call control server, wherein said call control server sets 
up call control structures to communicate with devices 
in said packet network via said asynchronous interface 
for controlling media streams from and to said devices; 

a voice media server communicating with said call control 
server, wherein said call control server uses said call 
control structures to establish media streams between 
said devices and said voice media server via said 
asynchronous interface; and 

an application server communicating with said call con- 
trol server and said voice media server, wherein said 
application server instructs said call control server to 
redirect said media streams to be transmitted directly 
between said devices without passing through said 
voice media server, and wherein said call control 
structures are retained between said devices and said 
voice media server, and said voice media server con- 
tinues to receive a copy of said media streams while 
said media streams are redirected. 

206. The system of claim 205, wherein said devices are 
network gateways. 

207. The system of claim 205, wherein at least one of said 
devices is an Internet Protocol (IP) phone. 

208. The system of claim 205, wherein said call control 
structures each comprise G.931 standard call signaling and 
H.245 standard call control. 

209. The system of claim 205, wherein said media streams 
are real-time protocol media streams. 

210. The system of claim 205, wherein said media streams 
are real-time control protocol media streams. 

211. The system of claim 205, wherein said packet 
network is the Internet. 

212. The system of claim 205, wherein said media is 
voice. 
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213. The system of claim 205, wherein said media is 
selected from the group consisting of: voice, video, 
multimedia, and combinations thereof. 

214. The system of claim 205, wherein said first and 
5 second media streams comprise the same data type and data 

rate. 

215. The system of claim 205, wherein said first and 
second media streams comprise different data types and data 
rates. 

0 216. The system of claim 205, wherein user input indi- 
cation messages are transmitted out-of-band from said 
media streams. 

217. The system of claim 216, wherein said user input 
indication messages are transmitted in at least one of said 

15 call control structures. 

218. The system of claim 216, wherein said user input 
indication messages comprise dual tone multiple frequency 
(DTMF) signal messages. 

219. The system of claim 216, wherein said user input 
20 indication messages are generated one of said devices. 

220. The system of claim 205, wherein said system is a 
packet voice response unit. 

221. The system of claim 220, wherein said packet voice 
response unit provides an enhanced service selected from 

25 the group consisting of: prepaid calling card service, post- 
paid calling card service, collect calling service, interna- 
tional callback service, one number service, voice activated 
dialing service, conferencing service, and combinations 
thereof. 

30 222. The system of claim 205, wherein said asynchronous 
interface is an Ethernet connection. 

223. A method for redirecting media in an asynchronous 
packet network by a system asynchronously connected to 
said packet network, said method comprising: 
35 establishing a first call between a first device and said 
system via said packet network, wherein said first call 
comprises a first call control structure and a first media 
stream; 

establishing a second call between said system and said 
40 second device via said packet network, wherein said 
second call comprises a second call control structure 
and a second media stream; 
signaling said first device to redirect said first media 
stream to a second device, wherein said first call control 
45 structure is retained between said first device and said 
system, and 

signaling said second device to redirect said second media 
stream to said first device, wherein said second call 
control structure is retained between said system and 
50 said second device, and said system continues to 
receive a copy of said media streams while said media 
streams are redirected. 

***** 
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